Andrea Danti - Fotolia
Puppet Inc.'s State of DevOps Report keeps growing. The report aims to show the changes and growth across DevOps in the enterprise this past year and to help IT leaders understand the trends in the industry. In fact, in the four years Puppet has published the report, there have been over 25,000 responses from people working across all industries and verticals -- not just tech companies, but highly regulated industries like insurance, healthcare and government. Furthermore, 25% of responses came from large enterprises with more than 10,000 employees.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
One of the most useful ways to interpret this report is to look for commonalities among organizations using DevOps to successfully deploy quality products. This year, the report shows that a loosely coupled architecture and team is one of the strongest indicators of continuous delivery and DevOps success. This points to an emerging pattern regarding one of the most effective ways to structure your architecture toward this goal -- in the form of microservices.
So, how can you decompose monolithic applications into microservices to power your business forward? Based on a recent discussion I had with Jez Humble, CTO of DevOps Research and Assessment and a principal author of the State of DevOps Report, there are some key points to share.
Low performers sacrifice stability for speed
Before diving full-steam ahead into the world of microservices, let's quickly look at some of the numbers from the report. One of the most amazing statistics to come out this year is the fact that high-performing teams are doing releases 200 times more frequently than their low-performing counterparts. Not only are they releasing much more frequently, but the same high-performing teams are able to move 3,000 times faster in terms of lead teams. This means releases now happen in the span of hours, not months.
While these numbers are staggering, it is worth noting that the gap has actually closed somewhat. Humble attributed this not to actual improvements, but a sacrifice in stability.
We're seeing that what's happening is the low performers are moving faster, but they're not yet actually finding ways to create more stability. And they're not putting in the work to actually make sure that those fast releases are more stable. You see that when companies are like, 'We must go faster, but we're not going to invest in test automation and deploying automation,' this is the result. You end up going faster by actually breaking things because you've got to do the work of actually improving the culture and implementing the practices.
Architecture comes first
So, the evidence is there -- DevOps works, especially when organizations are invested in the tools, organizational structure and processes to make it successful. One of the key steps toward achieving this type of success is establishing a loosely coupled architecture through the use of microservices. Architecture is the single strongest predictor of the ability for an organization to effectively practice continuous delivery -- it's stronger than test automation, deployment automation and continuous integration.
At its highest level, and in the words of Humble, microservices are "a suite of services -- each service focused on doing one thing well." It is the process of attempting to break down a complex problem into constituent pieces, each of which have their own area to focus on, allowing organizations to divide and conquer, develop expertise that allows faster development times and, ultimately, streamline their development pipeline and produce better releases, faster.
But if you are currently servicing a monolithic application, the prospect of achieving a loosely coupled architecture, or breaking it up into microservices, can be daunting. Some of the challenges you will face are state management, transactional boundaries and, simply, headcount for managing a great number of microservices.
Getting a grip on your loosely coupled architecture
But like the premise behind microservices themselves, the best way to walk a journey of a thousand miles is one step at a time. By focusing on one service and getting it to the point that it's functional before moving on, it can make breaking up a monolith simpler.
One of the ways to do this is through an approach called Martin Fowler's Strangler Application pattern. Though this methodology was first defined in 2004, before the development of microservices, it is well suited as an approach to breaking up monoliths into microservices.
The Strangler Application is based around the analogy of a vine that strangles the tree it is wrapped around. By using the structure of the application itself, you can divide an application into different functional domains, and then replace them with microservices one at a time. When you do this, you essentially create two separate applications that live side by side, and, over time, the new application will replace (or strangle) the old one -- at which point you can shut it off. The Strangler Application helps you to divide and conquer by using the monolithic applications inherent divisions and building within that framework.
How many microservices are too many?
If you're planning on restructuring to a microservices model, you might be wondering how many separate services to make with the original chunk. Ultimately, it's about reaching a balance that lets you get DevOps benefits without restressing your development and management teams.
Will it go perfectly? Likely not. You will get it wrong the first time. Just assume that you're getting it wrong and you're going to have to adjust along the way. Don't get too upset about that. Look for scenes; look for places where there are API boundaries, code that's kind of independent. Focus on single capabilities, and maybe you'll find some low-hanging fruit that you can start to pull out into separate services.
You can also take the strategy of looking for code that you are already changing a lot. If there is a specific section of your application you find your team working on and recoding many times, that would be well suited to become its own microservice in the future.
Trust in automation
Another good starting point to approaching microservices and a loosely coupled architecture is to try to break your application up into as many small microservices as possible. By keeping the bites small, it will have less impact on the overall application as you began to break it into pieces. Of course, that also means you will have that many more services to support. With that in mind, it will be helpful to bake in as much automation as possible, particularly with automated testing. Another way to make microservices more manageable as you attempt to break apart you monolith is by employing self-service automation. By empowering your development teams, they won't have to wait for environments and you can work much more efficiently.
Overall, microservices are an outstanding way to approach continuous delivery and help power your DevOps transformation. If you find yourself faced with the challenge of breaking up a monolithic application, taking a bite-sized and iterative approach will help make the transition easier, keep your application moving forward and help you take a crucial step toward making continuous delivery a part of your business strategy.