Why is 2015 the first year of microservice architecture?

[[127190]]

Editor's note: Microservice architecture (MSA) is an architectural concept that aims to decouple solutions by decomposing functionality into discrete services. You can think of it as applying many SOLID principles at the architectural level rather than at the class that gets the service. Microservice architecture is an interesting concept. Its main function is to decompose functionality into discrete services, thereby reducing the coupling of the system and providing more flexible service support.

【51CTO Translation】Microservice architecture began to gain attention in 2014 as a way to speed up the development of web and mobile applications. This year, more enterprise organizations will reap the benefits of microservices.

The concept of building applications using services has always been attractive. Why write code from scratch when you can just assemble multiple applications that leverage the same services through standard APIs? As long as you configure those services correctly, you should be able to gain huge economies of scale.

In the past, attempts to implement this concept have failed under the weight of over-engineering (particularly the CORBA and SOA trends). But one of the most interesting aspects of microservices is that their use has been a grassroots phenomenon driven by developers. Basically, microservices are small, single-purpose programs accessible through an API. This time, the service concept has won the hearts and minds of the people.

To see a real-life example of microservices architecture, just look at this 2014 blog post: How we build microservices at Karma by Stefan Borsje, CTO and co-founder of Karma, a company that sells wireless hotspot devices to consumers. According to Borsje, the company’s development team “accidentally used” microservices when developing an online store.

We started with a large backend application and broke it into parts when necessary. As we continued to build the application, it became clear what problem we were trying to solve; and the more familiar we became with that problem, the more obvious it became that we needed to set boundaries for the different parts of the application. Whenever we encountered a component that should have been a standalone part, we turned it into a service.

At first, these parts were relatively large, but as with other users adopting microservices, we found that those parts could become smaller and smaller.

For example, the monolithic application originally had a "store" component, which Borsje's development team broke down into services such as order processing, order fulfillment, and tracking. Even the public-facing front end was broken into multiple services. Borsje said that separating fine-grained functions into independent services has greatly improved work efficiency, in part because developers don't have to worry about all the dependencies of the monolithic application when developing.

For Karma, the biggest problem with microservices is testing. As Borsje said, "The actions and the end results are so far apart that it is difficult to find the exact cause and effect. There may be a problem in the whole chain, but which link in the chain is broken?"

Martin Fowler, co-author of the Agile Manifesto, laid out the reasons for favoring microservices last March, and followed up with a presentation in November that outlined a multi-tier microservice testing system in some detail. Not surprisingly, he supports unit testing of individual services, though he acknowledges that this is not enough to determine if the entire system is working properly. He thoughtfully lays out a series of integration, component, contract, and end-to-end testing strategies that will hopefully help developers make sense of one of the trickiest issues with microservices.

Another problem: you can’t always predict which microservices might not be able to keep up with demand in certain situations. I’m sure this is one reason Karma deployed its e-commerce platform on Amazon Web Services (AWS). In AWS, autoscaling adds compute power where it’s needed, helping to ensure that no one service becomes a bottleneck. Note: Netflix, the poster child for microservices, also uses AWS—in other words, microservices and the cloud go hand in hand. In theory, you could build your own private cloud with autoscaling using VMware or OpenStack, but doing so is difficult, which is a big reason why public clouds win.

Another popular technology that supports microservices is Docker, which is used to package applications and then deploy them in Linux containers. Microservices and Docker have proven to be a match made in heaven, which is a big reason why all major public clouds now support Docker.

Obviously, no one is claiming that microservices are the answer to all problems. But the microservices architecture is likely to succeed where other service-based solutions have failed because it emerges from the bottom up. Developers determine the types of services and the granularity of the services; as this trend spreads to large enterprises, development teams will be able to decide which services are best-in-class for the entire enterprise.

This ad hoc build-out would not have been possible with the hardwired infrastructure of the past. Equally important, developers have become much better at collaborating, a cultural shift that helps software architecture build naturally and orderly, rather than following orders and regulations from above.

From what I’ve heard, developers in many organizations are already adopting microservices architectures, whether management knows about it or not. With the right cloud infrastructure, whether public or private, microservices architectures can not only make developers more productive, but also help them build new types of applications that were not possible before.

Original English text: Why 2015 will be the year of microservices

Bugatti Compilation