The Microservices age

How often have you heard this new term lately? Microservices. What does it mean and why it is important to you? And why software architects need (if they didn't do it yet) to think carefully before taking a decision to build a new enterprise application?

There are tons of excellent articles written about micro services. My intention is not to give you another article, but to resume the best ones I read and give you a first approach to this architecture.

For example, in this article Martin Fowler and James Foley define the "Microservice Architecture style" as an approach to develop a single application as a set of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around business capabilities and independently deployable by fully automated deployment machinery.
Furthermore, the services may be written in different programming languages and use different data storage technology. They can even be managed by different teams.

To illustrate this idea, think about the usual way of approaching the building of a new enterprise application: a monolithic application built as a single unit.


If you needed to build a new enterprise application you will normally think of an application built in three parts: a user interface, with HTML pages and javascript in a browser on the client's side. A database storing all the data, and a server-side application who can handle the requests from the client, look for the requested information in the database, perform some logic and then render the results back to the client. This application is a monolith: a single logical executable.

Over time, as the project matures, as you add more developers on it, as it grows and the code base gets larger and the architecture gets more complex, that monolith is going to add overhead into your process. And the software development lifecycle that once run smoothly, now is starting to slow down. (What led Amazon to its own services architecture)
I've seen a lot of these examples at my clients.




Now, why would you like to broke down your software into multiple component services? So that each of these services can be deployed, tweaked and then redeployed independently without compromising the integrity of an application. (smartbear.com )

What are the main characteristics of the microservices architecture?

  1. Componentization via services. When you start to break down your application, you need to think of your services as components. Components that will have boundaries, components that will be independently deployable. 
  2. Microservices are organized around business capabilities and priorities. Unlike a traditional development monolithic approach - where different teams each have a specific focus on UIs, databases, server-side logic, etc. - microservice architecture utilizes cross-functional teams.
  3. "You build it, you run it". This is an Amazon's maxim to explain how a team should see, through the microservices lens, the product as its own. His commitment does not end at the end of the project, when the product is delivered, but continues when its deployed in production and beyond. 
  4. Smart endpoints and dumb pipes - the effort, the stress put on the communication between the processes shouldn't be in the structure itself (like an ESB or BPEL) where we can find sophisticated tools like orchestration, message routing and choreography. Instead the communication should be through simple RESTish protocols and lightweight messaging. 
  5. Considered particularly ideal when you have to enable support for a range of platforms and devices. (spanning web, mobile, Internet of things and wearables).
  6. Continuous delivery.  The teams which will build the software should be prepared to make extensive use of infrastructure automation techniques         


Amazon, eBay, Twitter, The Guardian, Netflix, PayPal, SoundCloud and many more large-scale websites and application have all evolved from monolithic to microservices architecture.

As I mentioned before, this is a just a first approach to the microservices universe.
I hope you enjoyed it!

Comments

Popular Posts