devopsy.kinsta.cloud

Tag: microservices

Will Microservices Make the ‘Ops’ in ‘DevOps’ Obsolete?

DevOps is a portmanteau of “developers” and “operations.” The concept of DevOps is about shifting IT culture in a way that enables developers and operations to work together more seamlessly. As more and more elements of DevOps become automated and leverage microservices such as container platforms, though, the operations side of that equation plays a diminished role.

Microservices and Automating Ops

What you’re left with essentially is developers with the processes and tools to automate the infrastructure back end. Technologies such as containers and services such as AWS Lambda simplify greatly the process of programmatically generating, modifying and maintaining the underlying infrastructure.

AWS Lambda seems to be a step toward removing the Ops from DevOps. It creates a system for use and runs code via APIs. The instance is spun up, the code is run and the instance is spun back down. AWS Lambda can decrease provisioning time and enable developers to be even more efficient than working with traditional virtual machines in partnership with operations.

Container technologies such as Docker allow applications to be broken down into very granular elements—many of which can be leveraged repeatedly. The ability to reuse containerized functions across different apps and to drive that process through APIs enable substantially greater automation.

With each step forward in the evolution of DevOps, organizations find new bottlenecks or roadblocks, and then look for or develop solutions to address them. In this API-based, automated future, the APIs themselves become a challenge. Organizations have to find ways to effectively manage and update a rapidly growing library of APIs.

Ops Will Live On

If you work in operations, or aspire to someday work in operations, don’t fret: Operations still will exist on some level.

The role played by operations will simply evolve. “Operations is not going away, but the job is definitely changing,” says Shannon Williams, VP of Sales and Marketing at Rancher Labs. “Automation and microservices are technologies that are enabling operations teams to spend less time ‘firefighting’ to maintain configurations, etc., and more time on bigger-picture issues that will help improve performance and resiliency, [and] help bring down costs for the business.”

That’s a step in the right direction. In this future scenario—next-gen data center—those in operations will be able to invest their time in more valuable endeavors. They will be able to automate routine, mundane infrastructure tasks and focus on incorporating new technologies that enable the organization to derive greater value from DevOps and IT in general.

“What is going away is the time spent arguing about what went wrong, not operations itself,” Williams suggests. “Given the additional time that automation will free up for Ops, they can start to find ways to improve their specific business unit. They can now be focusing on optimizing for performance, costs, etc.”

Evolution of DevOps

I have pointed out before that every roadblock in DevOps is actually an opportunity. As DevOps principles are applied in new areas, and new tools are developed to automate more tasks, it just accelerates everything to the next bottleneck. Rinse and repeat.

To some extent, the infrastructure side of IT and DevOps are two of those roadblocks. That’s why tools are emerging to allow many components of infrastructure to be automated, freeing the operations team to focus its efforts on whatever the next roadblock is.

January 26, 2016
How to Handle DevOps Microservices (Hint: Carefully)
Given the dizzying amount of best-of-breed tools that can be involved in the development pipeline, a well-written microservice comes to the rescue with just enough code to keep things running. But too much of anything is never good. Here’s how and when to use microservices.

Microservices are all the rage right now: these mini-apps are being used to integrate distributed applications that can be modified more easily. Microservices act like the glue, holding together processes and systems in the DevOps automation workflows. This means faster, more automated cycles, better implementation of continuous delivery and increased visibility into DevOps processes and deployments.

For developers and testers, who generally love the best-of-breed approach of using whatever tool they prefer for the job, microservices allow them to do that by affordably connecting many different open-source and commercial tools in the DevOps pipeline. While some of these tools have built-in integrations to other popular tools, those integrations may not be exactly customized for your needs. Asking the vendor to build custom integrations for you can be cost prohibitive and may not be feasible within the time frame your organization is looking to implement.

So with microservices, development teams have the flexibility to build their own tool stack and integrate everything to achieve full visibility into the development process. Equally helpful, REST APIs are super easy to work with compared with legacy APIs; developers can handle writing microservices without specialized expertise in the products that are being integrated. These are just a few of the extremely powerful advantages of the microservices approach.

Yet as with every other cool technology, there are a few hitches, as follows:
1. Hard to handle. Microservices depend upon vendor APIs, and when those change, the service will break. Then, you’ve got to rebuild the service from scratch. That is a time-consuming task that detracts from the main job at hand: writing and refining code. In an environment with hundreds of microservices, pretty soon, you’ve got developers spending the bulk of their time updating those pesky mini-apps in your devops pipeline instead of building new user features. Costs escalate and timelines slip.
2. Slapdash processes. Let’s face it, when you’re writing a microservice just for your team, you’re going to do it as quickly as possible, thereby skipping a few steps that can make the microservice less fragile. A vendor, meanwhile, writes a micro-service to help hundreds of customers – therefore, it’s got to be bulletproof. The internal approach for integration through microservices can be more prone to breakage. Once one service breaks, there is the inevitable domino effect with other integration points, meaning down time in your development process.
So, now what? It’s possible to make all this a bit easier. First, make sure that you’ve got the economics straight. Will developing microservices as your integration strategy be cheaper (factoring in staff time) than having vendors do it for you? If cost is not the main consideration, do the benefits of having a custom-built DevOps tool stack outweigh the complexity issues including downtime risks when a service breaks? Is there a clear-cut benefit from having a custom integration over taking the vendor’s not-quite-perfect integration? Do the analysis before choosing the microservices path – and remember to tie all this back to business benefits.

Here are some ways to reduce the complexity of microservices:

Go hybrid: In most cases, organizations will find that using a combination of vendor integrations and microservices is often the answer.

Outsource: For business-critical applications, it’s not a bad idea to let an outside development firm handle the microservices portion for you. That will reduce your risk and free up your developers to focus on building products not managing integrations.

Tools and languages: Choose languages for writing microservices that work well with REST APIs, such as Python and Ruby. As well, keep an eye out for tools that can help when you’re doing this in-house, such as Zapier or TaskTop. We expect those automated options to only grow, as companies expand their use of microservices and containers to optimize their DevOps operations.

About the Author/Kevin Dunne

Kevin Dunne is the vice president of strategy and business development at QASymphony. He has a deep interest in the emerging trends in software development and testing. Kevin joined QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. He can be found online at LinkedIn and Twitter.
November 2, 2015
Microservices, Hyper-Complexity, and Automation
Imagine building a human being one DNA codon at a time. Sure, you might be able to build a pretty awesome individual. But it would take a long, long time. And you’d only be able to build one. Worse yet, if you didn’t get your person exactly right on your first try, it would take you another long, long time to come up with Version Two.

Unfortunately, this is exactly the position many companies are putting themselves in with microservices.

Yes, microservices theoretically enable companies to adaptively recombine their digital DNA to build the increasingly awesome apps. But without better automation, they won’t be able to do so very quickly—or very reliably.

Hyper-Complex DevOps

Microservices introduce significant additional complexities into the DevOps lifecycle. Each microservice has its own data mappings, APIs, latency/performance dependencies, etc. So, while microservices may offer genuine advantages in terms of adaptability and re-use, they also multiply the total number of discrete DevOps tasks—especially vis-à-vis test/QA—by at least one full order of magnitude.

This is a serious problem for shops that aren’t sufficiently well-automated, because any task—or, as is much more often the case, any handoff between tasks—that is not well-automated will quickly turn into a bottleneck.

The resulting adverse consequences of insufficiently automated microservices DevOps can thus include slow delivery, excessive cost, and mistakes. Worse yet, chronic bottlenecking will likely create a pervasive organizational disincentive that fundamentally undermines the microservices initiative itself.

What Automation Entails

Thorough, effective DevOps automation is, of course, more easily aspired to than achieved. To implement the kind of end-to-end DevOps automation required for microservices success, organizations have to get three things right:
- Process mapping. Effective automation requires an exhaustive definition of process. This exercise is not for the faint of heart—because most organizations have many pockets of ad hoc process at various points in the DevOps cycle. Test/QA tends to be especially variable based on factors such as the delivery pressure teams are under at any given time.
- Automation technology. Development teams often use scripting and other technologies to automate various DevOps tasks. An overly fragmented automation environment, however, can be difficult to orchestrate and manage. So the move to microservices may necessitate a more holistic integrated automation environment.
- Leadership and culture. A well-automated DevOps process alone is insufficient for microservices success, because it is unfortunately not true that “if you build it, they will come.” On the contrary, a strong leadership commitment is essential for changing the way people work.
The application economy is putting development organizations under intense pressure to be more productive and responsive to ever-changing market dynamics. Microservices offer one possible way to respond to that pressure. But microservices won’t work without a much more rigorous approach to DevOps automation. IT leaders may therefore want to focus on automation first and microservices second, instead of the other way around.

Unless, that is, you only want to build one app using microservices—and then maybe build a slightly better one a few months later.
October 19, 2015
4 big challenges of microservices

The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.

First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.

Al Hilwa, research director, Application Development Software at IDC described microservices this way:

“Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.

Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.

1. Insufficient guidance

When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.

2. Getting it wrong

There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.

3. No going back

You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.

4. Deliver value

Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.

Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.

September 21, 2015
Microservices define the next era of IT

There is a lot of focus on DevOps and container technologies these days. Both are very strong trends in IT on their own, but each is also proof of a larger shift in IT culture to a microservices architecture. A new report from IDC titled “The Emergence of Microservices as a New Architectural Approach to Building New Software Systems” takes a closer look at the evolution and impact of microservices.

Let’s start with the obvious question: What exactly is microservices? “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades,” said Al Hilwa, research director, Application Development Software at IDC. “Microservices architecture is enabled by a spectrum of tools categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

Put another way, microservices is an umbrella term that applies to breaking systems and applications down to a more granular, modular level. Containers are an example of taking an application and making it into a self-contained component, and DevOps provides the framework for developing, deploying, and managing the container ecosystem.

By some interpretations microservices and containers are somewhat synonymous. In other words, microservices is just another way of saying that an organization is using container technologies for app development and deployment. IDC classifies microservices more broadly, saying it is based on an approach to organizing software development—more of a concept and less of an actual product or technology.

The Wikipedia definition of microservices sums it up like this: “In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”

Although the concept of microservices is broader than the underlying platforms or tools it uses, IDC acknowledges that the advancements in software development and deployment methodologies—namely DevOps and container technologies—has played a pivotal role in elevating microservices to where it is today.

The transition from a traditional hardware server infrastructure in an on-premise datacenter to a cloud-based, software-defined infrastructure that can be created, modified, or removed programmatically offers significant benefits for organizations. The microservices architecture enables companies to be much more agile and cut costs at the same time.

There are some challenges and concerns as well, though. Hilwa notes, “Microservices architecture, by its very nature, is distributed and operates across networks and can thus exact significant performance penalties that must be accommodated with architectural solutions, like caching layers and API management and optimization techniques.”

In the IDC report Hilwa talks about the need for strong organizational support and an overall shift in the IT culture in order to succeed with microservices. As Hilwa puts it, “Organizations have to increase their tolerance for risk and learn to fail gracefully, fast and often in order to achieve success.”

Hilwa provides a comprehensive overview of the current state of microservices in the report along with some prescriptive guidance for organizations that are either just trying to understand what microservices is, or those that have already waded into microservices but want a better appreciation for the benefits and pitfalls.

July 15, 2015
Top 5 Anti-ESB Arguments for DevOps Teams.

Unix and Mac. Developers are always in combat. My last verbal combat was a “discussions” around ESB and Microservices. They are fun because both supporters tend to have very strong opinions about what they think is best and both want to fight each other. I recently got involved in one of those discussion about ESB vs. Microservices and the ESB guy throw lots of arguments at me. “ESB is magic” got almost burnt into my mind until I started to investigate a bit: “How to fight ESB discussions in combat?”. Here are my top 5 findings that may help in your next verbal ESB combat situation.

(more…)

July 6, 2015
DevOps Leadership Series: Monitoring Containers and Microservices

Trevor Parsons (@trevparsons) is a Co-Founder and Chief Scientist at Logentries, a leading SaaS-delivered log management and analytics service. I caught up with Trevor at the Velocity Conference in Santa Clara and asked him what themes were resonating with attendees this year.

For this episode of the DevOps Leadership Series, Trevor briefly illustrates some current problems with state of microservices and container-based architectures, while sharing a positive outlook for the future.

https://www.youtube.com/watch?v=zHRE4011WVk

Trevor says there’s been a lot of development in how to log and monitor containerized systems and he sees better support from Docker for logging, showing an increasing focus on this topic in 2015 and beyond. He anticipates the next year to have huge improvements in managing and monitoring these new systems and architectures.

Next up in the DevOps Leadership Series, I headed to London for the DevOps Connect: Rugged DevOps event, where we’ll discuss more about Rugged DevOps practices. In London, I was able to catch up with Helen Beal (Ranger4), Justin Arbuckle (Chef), and Gareth Rushgrove (Puppet Labs).

If you have missed any of the other videos from this series, you can find them here. (We’re up to 15 so far).

June 11, 2015
Launching Applications to the Cloud – It’s all about Scalability and Speed
It is not hyperbolic to state that today’s web services deal in hyperscale realms when one considers stats such as
- The Amazon cloud can handle up to 1 million transactions per second during peak loads
- Facebook was managing 890 million daily active users on average for December 2014
- There are 500 million tweets sent per day and 80 percent of those are sent from mobile devices
Ironically, the move to hyperscale web services has been made possible by applications going micro, as in microservices as commonly defined as “small, independent processes communicating with each other using language-agnostic APIs.” The emergence of microservices based application architectures is a revolutionary departure from monolithic app development, which was purpose-built around a single service, e.g. storage management, CRM, etc. In its place now are 10 or more modular, reusable services each owning a limited and specific set of functionality in what might be best illustrated as replacing a singular black box with a set of Lego blocks.

In turn, this has led directly to key advancements in the application development process, evolving from start-to-finish programming to agile, continuous integration/continuous development (CICD). This model offers two major advantages over the waterfall development approach:
- One, decreasing software development time to align to the “speed of business” dictated by market factors and not by IT processes.
- Two, enabling specific modules of an application to achieve “autonomous elastic scale” where instances can be scaled up or down dynamically and on an as-needed basis.
The software world and its professionals are intimately familiar with these application megatrends, of course. They live it every day. However, they may be less familiar with what’s happening — or to be more precise what’s not happening — with the evolution of networking, specifically in the layer that manages server load balancing or application delivery control (ADC).

This is so because legacy ADCs were built and optimized for applications that resided in a single hardware platform and at a single location. With the advent of Microservices, the days of a cozy 1-to-1 relationship between the ADC and a monolithic application is quickly becoming a thing of the past. A useful analogy here is to equate the management of these resources with how humans treat cattle vs. pets.

Application microservices are like cattle in that while these resources are valuable, each resource can be easily replaced. Legacy ADCs are like pets in that they’re not easily replaceable and, at times, require painstaking levels of care and attention. Indeed, it is clear that the pace of innovation for these networking devices has not kept pace with the requirements of application microservices in their current forms as either hardware appliances or as self-contained VM appliances.

Though legacy ADCs may be upgraded to be microservice “aware” and even provide certain levels of integration; they are not optimized to support an application architecture that’s built on microservices written in different programming languages and distributed across many different hardware platforms, clouds, and even data center locations.

The solution requires ADCs and load balancers to evolve to take on more of the characteristics microservices possess (be more like cattle and less like pets), namely:
- Being tightly aligned with each app microservice and not with the entire monolithic app;
- Delivering a consistent set of network services in a location-agnostic way, whether the app location is on-premises in a data center or distributed across private and public clouds;
- Being hardware agnostic, whether the app is on bare metal, in VMs, or even in containers – without requiring additional configuration tools; and
- Achieving autonomous and elastic scale to support each microservice throughout its useful lifecycle.
Further, this evolution must be true and profound and not a mere incremental advancement, which has hindered the adoption of software-defined data centers among the large enterprise segments thus far.

Specifically, ADCs must achieve the concept of “application affinity” which is based on the app-world concept of “processor affinity” where resources are aligned/pinned for specific functions. There are two major benefits to this approach. First, having the ADC resource side-by-side, the microservice will improve the application response time. The application delivery follows the “destiny” of the microservice – it grows, shrinks and moves with the app itself.

Second, this tight alignment (affinity) enables ADC resources to achieve automatic lifecycle management of microservices without manual intervention, which reduces management complexity significantly.

In summary, it’s been said that best things tend to come in small packages. Such is the case with the emergence of application microservices, which has paved the way for agile, continuous application development and hyperscale web services.

It’s time for the ADC to undergo a similar evolutionary path in order to maintain its strategic value as the gateway between the network and application layers.

About the Author/ Dhritiman Dasgupta

Dhritiman Dasgupta the VP of Marketing Avi Networks.Prior to joining the Avi Networks team, Dhritiman Dasgupta (aka DD) was a Vice President at Juniper Networks where he headed up the data center, security, and SDN marketing efforts. He launched the award-winning QFabric and MetaFabric systems. Prior to Juniper, DD spent 9 years at Cisco Systems in the LAN and Data Center switching divisions heading up product management for several multi-billion dollar platforms including the Catalyst series switches. https://twitter.com/mandhriti
June 8, 2015
Top 3 DevOps Practices for Operational Stability

Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.

(more…)

June 4, 2015
What’s hot with DevOps

DevOps as a movement to transform people, technology, processes for higher business value is here to stay. It’s disrupting organizational processes replacing the old with the new. Command and control IT, a historical approach to regulating tech top-down, is trending toward decentralization thanks to DevOps.

Software source control is another such case. We saw Git take on the source control bigwigs and redefine how we collaborate and build software. Now, which other areas is DevOps disrupting?

What’s hot with DevOps?

Application services

We have a famous saying in my home country Spain, The King is dead, long live The King! I say, “The application is dead, long live the application.” I’m referring to the practice of implementing applications as monoliths. Monolithic applications are a dying concept. Why? Because it’s better to design them as a collection of services that link together. Such a flexible structure allows service reuse and control at a granular level. And you manage their lifecycles independently. Attempting to control these services centrally though is the equivalent of trying to balance the federal budget.

It’s challenging to manage the lifecycle of services because of the very nature of agile business decision-making. Since services are much more granular, managing their lifecycle is also such. That’s why current application lifecycle management tools do not scale for service-oriented applications. Next generation application lifecycle management requires a focus on the service not on the application.

Microservices and Docker

Microservices is to infrastructure what service-oriented architecture (SOA) is to applications. Next generation applications require agile infrastructure to sustain the cadence of faster releases. Microservices align infrastructure management to the much more granular world of application services.

Over the last year, microservices gained traction fueled by the container revolution. The unit of infrastructure shrank from a VM to a container allowing applications to run as a composition of smaller self-contained services making application releases that much more agile. So my second bet is on containerizing application services.

Hybrid and multi-cloud

Third, cloud infrastructure management tools must scale to the next generation of the container and service-ready applications. In the world where infrastructure is a service, application architecture can no longer rely on infrastructure implementing a particular way. A development or QA environment does not have the same SLA needs or constraints of a production environment as an example. So applications must be able to run across a diverse infrastructure.

The first generation cloud management tools focused on managing servers in public clouds. That focus made every infrastructure provider a special case. Special cases don’t scale though. The cloud management tools must scale by removing dependencies between applications and infrastructure. Thereby, infrastructure becomes a choice, not a dependency. Application services must be able to run in private, public, hybrid, or multiple cloud environments. Such elasticity and independence are what applications demand from infrastructure.

Having been in this space for more than a decade now, I live and experience these DevOps trends daily. What are your thoughts, are there any trends you’re following closely?

May 26, 2015