Today’s monolithic applications are starting to become too big and too complicated for developers to maintain. When developers want to update a feature, they are forced to update the entire application. To solve this problem, organizations have been turning to a new software development approach: microservices.
“Microservice architecture is the idea that rather than building large monolithic applications, where you have one enormous thing that tries to cover thousands and thousands of different pieces of functionality and lots of different business services, we are going to try to break these out into smaller components, each of which represent an individual business action,” said Andrew Phillips, vice president of product management at XebiaLabs. “And then we are going to treat them as independent applications, which can be written and easily updated.”
Monolithic applications have served the software development industry very well for the past 10 to 15 years as organizations have been delivering solutions in the enterprise and on the Web. But when organizations look to deliver software on a continuous basis, the monolithic architecture falls short, according to Bob Familiar, practice director of cloud and services at BlueMetal Architects, a Boston-based software consultancy.
“The reason is that as you are making changes to that software, you are touching the entire surface area of that solution,” he said. “So things like regression testing, any time you touch it, add content, add a new capability, the entire system needs to be regression tested, has to go through the testing stage, and then the entire software product has to be put into production. That is a very heavyweight operation.”
The promised benefits of microservices
Moving to a microservice architecture is no easy feat. As with any other methodology, it takes time, money, dedication and a culture change to bring a new world of development into the life cycle. But do the benefits outweigh the costs? That depends, according to Phillips.
“Microservices is a promising approach, but adopt it with two things in mind,” he said. “Adopt it if you have a problem that microservices is likely to solve, and that typically is you are stuck and can’t deliver as fast as you need to. And don’t expect it to be an easy ride.”
Once you decide microservices are something that can help your organization, the benefits can be quite promising. “The biggest benefit is probably the speed of change, speed of adaption to new conditions, and speed of responding to new opportunities with new services,” said Pierre Fricke, director of product marketing at Red Hat.
Microservices also brings organizations an ongoing stream of improvement, according to Phillips. “Customers are expecting innovation and change at a much more frequent and incremental level,” he said. “With microservices, organizations don’t have to worry about spending time, expense and taking risks to push out so many changes at the same time. There is no more waiting six months for things to come out.”
The main benefit that can be achieved by microservices, if executed correctly, is autonomy, according to Sam Newman, technical consultant at ThoughtWorks and author of the book “Building Microservices.”
“A microservice can be changed and deployed independently of the rest of the system,” he said. “This means you get to make different choices about release cadence, technology, security and design idioms for each microservice if you wish. It also means that you can release functionality faster, as I can push out one feature without having to coordinate complex releases.”
In addition, microservices bring developers a new sense of empowerment and ownership, according to Phillips.
“There is nothing more frustrating as a developer than being stuck,” he said. “It is very difficult for you to make the thing you are writing better when it is just glued to this enormous monolithic application. It is very nice to be in an environment where you feel that you can move rapidly and you can improve rapidly. It is basically empowering developers by putting the power back in their own hands to make their part of the world better without being dependent on everyone else in the entire organization.”
Microservice architecture vs. service oriented architecture
In the past, organizations have turned to a service oriented architecture (SOA) approach to spilt up services into different components, but how does this differ from a microservices architecture approach? According to Newman, it doesn’t.
“Service oriented architecture is an approach that says that we can more effectively build systems, which are made up of collaborating services,” he said. “Microservices are exactly that. They are just more opinionated. In many ways you can think that microservices are to SOA what scrum or XP are to agile. So SOA is the general idea, where microservices are a specific way of achieving this idea.”
There are three tenets of microservices that are also fundamental tenets of service oriented architecture, according to Gary Olliffe, research director at Gartner.
The tenets include: 1) Keeping the consumption of services separate from the provision of services; 2) Separating infrastructure management from the delivery of the application capability; and 3) Separating teams and decoupling services.
“Microservices is a realization of those principles because it is much more specific in how it is described,” Olliffe said. “Although there are many ways of implementing microservices, the experts in the marketplace who are already championing the term ‘microservices’ and its patterns are being much more specific about what a microservice is and what it takes to deliver microservices.”
The main difference between the two is that SOA emphasizes functional distinction rather than business independence, according to BlueMetal’s Familiar. In the past, service-oriented systems were monolithic, and all the services were together in one big body of code. Microservices are about taking those services and splitting them up into autonomous, standalone software components with the ability to be developed and deployed independently, according to him.
“It’s an evolution from service oriented architecture,” said Familiar. “Interestingly enough, a lot of approaches that you use to design and implement microservices are really no different than how we have been designing service oriented architecture. We are still doing it the way we did, but we are going to package it up differently and deploy it differently so we can achieve that continuous delivery on a more granular scale.”
Transitioning to a microservice architecture
Before an organization even begins to adopt a microservice approach, there are four things it must do, according to Alistair Farquharson, CTO of Akana, formerly SOA Software. Those four recommendations are:
- Investing in and continuing to invest in your application
- Undertaking a complete re-architecture of your application
- Making the application suitable and scalable in a microservice way
- Having the DevOps maturity within your organization to support that application
Once an organization decides that a microservice approach is right for it, experts advise the following guidelines for transitioning:
- Understand the benefits. Organizations should be able to understand the concepts and the benefits of microservices before they even begin the process, according to Gartner’s Olliffe. “I have actually recommended that organizations take microservice principles and apply some of those to their traditional service oriented architecture as the first step,” he said. “Think about services as independently deployable units of functionality. Don’t bundle them all together into a single app deployment.”
- Start slow. “Don’t go nuts,” said ThoughtWorks’ Newman. “Don’t try creating hundreds of microservices at once. Chip one or two out from an existing monolithic system and get that into production. See what that experience is like.”
Don’t try to micro-size everything, according to XebiaLabs’ Phillips. “[Turn things into microservices] that are important enough to deliver real value to the business because that will give you the authority to then continue along this trend,” he said.
BlueMetal’s Familiar referred to taking a Strangler Pattern approach where you slowly build up services so that the monolithic application essentially fades away. “The idea is that you are going to, in an extremely phased approach, try to bring these microservices online over time,” he said.
- Define your services. “Not defining your services crisply and cleanly where they can interact and not disrupt the whole system is a big trap,” said Red Hat’s Fricke. “So define the services; what are the set of services that are going to compose the application?”
- Get your house in order with respect to automation. In order to get ready for automation, organizations should start with Continuous Delivery and Continuous Integration, according to Familiar. “That has to be foundational,” he said. “Automation is the way software can move through that pipeline at a reasonable velocity.”
Getting used to deploying something in a continuous way, even if it is a monolithic application, is going to be very helpful, according to Gartner’s Olliffe. “Once you switch to microservices, you are going to have many more things to deliver continuously to get the benefits from it.”
- Look at cloud platforms as a way to provide data center needs on demand. “The cloud platforms provide the elastic scale capability and the pay-as-you-go compute and storage,” said Familiar. “It is the platform on which you can build these very scalable software products that are being delivered in this continuous fashion.”
- Look for tooling that doesn’t expect you to describe all your services together as one enormous thing. “You have to be able to describe a service in its local environment without knowledge of the entire universe,” said Phillips.
- If you have large teams of developers, change the way they are organized. Teams that are organized, agile, team oriented, and hold all the different skills needed to go though development, testing and deployment are good at organizing how they build microservices, according to Familiar.
- Don’t start off with a rip-and-replace strategy, but an embrace-and-extend strategy. “You don’t necessarily rip and replace your existing monolithic applications; those things may be serving the back office and do it very well,” said Fricke.
Don’t try to spilt up your monolithic application all at once, according to Phillips. “Also, don’t say, ‘In order to do microservices, we need the brave new world where we are going to use a new runtime platform, new programming language, new set of technologies,’ ” he said. “We all know the more you try to bite off at the same time, the harder it is to chew. Make sure you pick your battles wisely.”
The dark side of microservices
While there are many promising benefits to the approach, there is also a dark side to microservices, according to XebiaLabs’ Phillips.
“Like anything else, there are no silver bullets,” he said. “You need to be aware that you are not necessarily eliminating complexity; you are moving it to a different place.”
In a microservices architecture approach, the complexity goes from inside the application—having to deal with one body of code—to the outside of the application—having to keep track of a lot of moving parts and how they interact, according to Phillips.
Gartner’s Olliffe referred to this as the inner and outer architecture of microservices. The inner architecture refers to each individual service. “That is the piece that gets simpler, and individual teams can choose that inner architecture to support their own specific services requirements,” he said.
The outer architecture refers to where developers are applying tooling from different disciplines to achieve a holistic machine that supports continuous distribution environments. The benefits of microservices need to outweigh the complexity that comes with the outer architecture of microservices, according to Olliffe.
“There is a lot less complexity in each service, but the pitfall there is that complexity never really goes away,” he said. “Each of these services have to be invoked, they have to be managed, they may need to communicate with each other, they may need to share some kind of status, but because they are isolated and loosely coupled, they have to do that using new design patterns. Failure to realize that the complexity doesn’t move is one of the biggest risks of microservices.”
“This is another reason to go gradually in your shift toward microservices rather than jumping in feet first,” added ThoughtWorks’ Newman.
An additional part of that complexity is being able to discover all the solutions in a microservice to ensure that a developer working in those services is working on the proper version of that service, and that the service is available when they need it to be. “Some kind of discovery service is typically built into the model so that it provides the necessary glue and cohesion to bring it all together,” said BlueMetal’s Familiar.
Testing also becomes very complex in a microservices approach, and developers will need to understand how to guarantee software is of the proper quality before releasing it, according to Newman. “This becomes even more challenging when you consider the fact that the behavior of distributed systems is often emergent, meaning it can be hard to the point of impossible to eliminate every potential bug in a pre-production testing world,” he said.
According to Familiar, testing needs to be done from 1) An internal perspective: All the frameworks the services are using, the internal class models and how they communicate inside the service have to be tested; 2) From outside the service, in order to make sure the API itself works; 3) At a protocol perspective to communicate properly and responsibly over the wire protocol being used; and 4.) At a composition level: What is supposed to happen, happens.
And lastly, one of the biggest challenges with microservices today is that it requires a high level of skill in order to be successful. “One of the truths unfortunately with microservices right now is that the best examples are organizations that have a very high degree of engineering and development skills,” said XebiaLabs’ Phillips.
If an organization doesn’t have a level of adaptability to be able to manage lots of services and their teams aren’t well versed, they are going to fail, according to Red Hat’s Fricke. That doesn’t necessarily mean that it can’t be achieved by beginner or moderately skilled developers, but until there are more best practices published and documented and more success stories rolled out, there aren’t going to be too many businesses accomplishing the approach successfully, he said.
“Right now you need a highly skilled set of people that can use modern lightweight tools and a leadership that can understand the big picture,” said Fricke.
In order for an organization to embrace microservices at scale, its teams need to adopt the mentality that they own and operate their own services, and the skill set inside these teams need to be broader than ever before, according to Newman.
“Understanding how your service fits in with the whole, knowing about failure patterns in distributed systems, taking more ownership of the tools and technology associated with deploying your service, and knowing how to monitor your services behavior in production and react accordingly are all important skills,” said Newman.
Building microservices
When Newman found himself spending more time in the cloud, Continuous Delivery and operations space trying to figure out how to help software organizations deliver high-quality software faster, he realized the most common challenge was the way systems were architected.
“All too often their design meant they weren’t amenable to change and the fast deployment of new features,” he said.
As a result of his findings, Newman was turned to microservices as a way to achieve faster software development. But the problem he came across with this approach was there weren’t too many materials that captured the benefits and tradeoffs of adopting this new architecture.
Coming to this realization, Newman spent more than a year writing “Building Microservices,” aimed to help organizations understand the advantages and disadvantages of the approach and providing some advice on how organizations can get started. Chapters covered what microservices are, the evolutionary architect, how to model services, integration, splitting the monolith, deployment, testing, monitoring, security, Conway’s Law and system design, microservices at scale, and bringing it all together.
“I really hope the book will help people understand the breadth of topics that are important to take into consideration when taking on a microservice architecture,” Newman said.
“It’s no silver bullet by any means. There are pitfalls aplenty. But for many of the organizations I work with who are trying to understand how to go faster, keep their people happy and engaged, and find that competitive edge, I think it offers a lot of benefits. I hope the book is an honest accounting of both the pros and the cons of the approach, together with enough detail to get you going.”
What are microservices?
“Microservices are the architectural approach that allows you to design your system in these small or autonomous components that do one thing and do it well,” according to BlueMetal’s Familiar.
Gartner’s Olliffe described microservices as “an approach to delivering application functionality that invites the functionality into very discrete units of execution and delivery.” According to him, teams on a microservice are small, consisting of up to five to 10 “technologists” who take on different roles such as development, testing, quality assurance and operations.
While microservices are definitely unique from traditional methodologies for developing applications, it is important to remember that they aren’t a replacement for them, according to Red Hat’s Fricke.
“The world will continue to be composed of back-office systems of records that don’t have the requirement to have rapid change, and they will continue to be developed using traditional methodologies and tools,” he said. “Microservices doesn’t replace the old way of doing things. It augments, complements it and gives you the ability to change the parts of your IT infrastructure you need to change very rapidly and on a continual basis.”
What’s the difference between a microservice and an API?
Some organizations may view microservices as a set of services made up of APIs, but according to Ian Goldsmith, vice president of product management at Akana (formerly SOA Software), the two are not one and the same.
“Microservices is a component architecture, not an integration architecture, and applications that are being built today that are leveraging microservices might be using APIs as well as microservices, but they are not intermittently connected,” he said.
The fundamental difference between microservices and APIs is that microservices are used to build applications, whereas APIs are used to integrate applications, according to Alistair Farquharson, CTO of Akana.
“If you think about a microservice, you don’t focus on the fact that it is a service or that it is an API,” he said. “You focus on how it helps you scale and build applications, and that sort of sets the tone for the microservice and the scope of the context of the microservice versus an API, which is how do I expose business functionality to the outside world? How do I integrate different applications that I have in my portfolio?”
According to Roberto Medrano, executive vice president at Akana, a new generation of APIs will be created as a result of microservices that move away from integration and reuse, and toward organizational and technical scalability and resiliency.
Characteristics of microservices
Microservices are a fairly new concept, and while there isn’t one definition of what the approach is or how to do it, there are certain characteristics that it should have, according to Martin Fowler, and chief scientist at ThoughtWorks, and James Lewis, principal consultant at ThoughtWorks.
Those characteristics, according to them, include:
Componentization via services: The most common way microservices will break down its components of software is by splitting them up into individual services.
Organized around business capabilities: The individual services should focus on the organization’s business capability, not the technology layer.
Products, not projects: Instead of using a project model where a piece of software is handed off to another group upon completion, development teams in a microservice own their service throughout its entire life cycle.
Smart endpoints and dumb pipes: “Applications built from microservices aim to be as decoupled and as cohesive as possible,” wrote Fowler and Lewis in an article about microservices. “They own their own domain logic and act more as filters in the classical Unix sense: receiving a request, applying logic as appropriate and producing a response.”
Decentralized governance: Microservices give developers the choice as to what languages and tools they want to use for each service.
Decentralized data management: Microservices are meant to be individual components of a software service. Therefore, in a microservice approach, each service manages its own database.
Infrastructure automation: Microservices should include infrastructure automation techniques such as Continuous Delivery and Continuous Integration.
Design for failure: Applications need to be able to endure failure.
Evolutionary design: “Microservice practitioners usually have come from an evolutionary design background and see service decomposition as a further tool to enable application developers to control changes in their application without slowing down change,” Fowler and Lewis wrote.
Fowler noted that these are just common characteristics of the approach, and not all microservices will have all of these features.
