Divide and conquer in software architecture
Applications built out of independently deployable modules are the future of flexible solution development
To innovate in customer engagement and to drive and adapt to digital disruption, enterprises must continuously change at increasing velocity.
Application development and delivery professionals must increase their velocity too, while also maintaining – better yet, improving – the quality and resiliency of what they deliver.
Large web-native and mobile-native players such as Netflix, Amazon, Google, PayPal, Uber, eBay and Yahoo, as well as startups and, increasingly, a broader community of enterprises are changing their software architectures to meet the challenge of continuous business innovation.
There are two major sides to this challenge – how and what. For the how, agile development and continuous delivery improve software delivery processes.
For the what, application programming interfaces (APIs), containers and microservices improve software flexibility and deployment, providing a central foundation for a quiet revolution in software delivery and stability.
Why microservices are important
Contrast microservices with monolithic applications. The distinction between them is, first of all, one of deployment, but it may also be a design distinction.
For example, a Java-based web application can be written as a collection of well-designed, modular Java classes. However, these classes are not designed for independent deployment, so all of them get packaged into one large file for deployment. Microservices refactor an application into a series of smaller, separately deployable units.
Read more about containers and microservices
Here are four considerations, from Jinesh Parekh of Idyllic Software for developers to weigh up when venturing into the world of microservices
Boyan Dimitrov, platform automation lead at Hailo, believes software development needs to change to keep pace with the demands of the modern world
There are four major benefits to microservices. First, when individual parts of a system are separately deployed, they can also be separately scaled. A system might need 20 running instances for one service and only two instances of another. Wal-Mart credits Node.js-based microservices for its ability to handle Black Friday volume spikes when other retailers had issues.
Second, separately deployed services can be implemented using entirely different platforms or design models. One service might need a huge in-memory database and a specialised programming language, while another might have a very small footprint and be written in JavaScript on Node.js. The order history service of Amazon’s retail store takes this principle further, using different implementations for recent orders and for older orders.
Third, when services are being run separately, it is more difficult for the whole system to go down at the same time, and a failure in processing one customer’s request is less likely to affect other customers’ requests. This is particularly true since each service’s operation can be optimised for its specific scale, performance, security and transaction management requirements. Netflix, for example, ensures resilience by periodically knocking out its own production services to be sure that the whole keeps running.
And fourth, microservices also offer more options for incremental development and deployment. Agile methods – and particularly continuous delivery – can move more quickly when parts of a system can be built and deployed independently. But even with waterfall development, a bug fix is easier to deploy with microservices. Prior to production deployment, smaller units of development allow for smaller tests, more frequent testing, more options for testing and more frequent feedback.
Components, APIs – or both
Industry discussions on microservices are quite vague concerning what they actually are. Breaking the word into its two parts helps to clarify the debate.
The “services” part of “microservices” has three potential meanings. First, “service” means a component-based, container-based deployable unit. This definition of microservices borrows heavily from early-2000s concepts of components, including the notion of marketplaces for components. However, it pushes beyond component-based development into individual deployment of each component. Operating system-level container technologies such as Docker are emerging as a primary means to structure an application as a collection of relatively small, separately deployable units. In this context, “service” is used in a general and generic sense of “doing something useful”.
Second, “service” means an API or messaging destination. In this definition of microservices, “service” is used in the specific sense of a network-accessible function, as with APIs, service-oriented
architecture (SOA), application messaging and message-oriented middleware (MOM). Most commonly, the implication is that the microservice would be a JSON/REST-based API, but other messaging styles and payload formats are also valid (AMQP, MQTT, SOAP, XML, Google Protocol Buffers, etc).
Third, “service” means both a component and an API. The first two definitions given here may be used together or separately. For example, microservices providing mobile APIs running on Node.js were behind Wal-Mart’s 2013 “no downtime on Black Friday” success story. The component definition is more important for deployment flexibility. The API definition helps mainly with application layering.
The “micro” part of the term is harder to clarify, but it does not necessarily mean small. A microservice should do one thing well – from the point of view of the service user – and this may be as small as a type-ahead API or as big as an API to initiate a complete e-commerce order fulfilment process. The real point is how size interacts with a system’s amenability to change. For this, one should begin with the two central principles of good software design: high cohesion and low coupling.
High cohesion is achieved by keeping together in one unit the things that change together. Low coupling is achieved by designing so as to maximise the degree to which unit A’s implementation can change without affecting the design or implementation of other units that refer to unit A.
A unit’s size fits with the microservices concept if it is highly cohesive, with loose coupling to other units. For service users, the order fulfilment API achieves low coupling by insulating them from ongoing changes in order processing. For developers building the internals behind the order fulfilment API, low coupling will make it appropriate to divide the API’s internal implementation into multiple separately deployable microservices.
How to start down the path to microservices
Microservices are emerging as an important part of the solution architecture for rapid and scalable response to business and technology change. But moving to microservices is not simple. It’s a journey.
The investments in and benefits from microservices can vary widely and, at the high end, can be quite high and strategic. Wal-Mart’s backing of the Node.js-based Hapi project represents an investment of more than $2m— and this is just one part of Wal-Mart’s microservice investment.
The microservice architectures for the Netflix and Amazon retail services are not merely online extensions, but rather the foundations of both businesses’ core business models. If enterprise use of microservices is limited in some way – for example, in a context where the rate of change is relatively low or for a contained mobile app context – an initial foray into microservices may provide limited benefit while allowing the organisation to take on the microservice risks and challenges one by one.
This article is an extract of the Forrester July 2015 report, Microservices have an important role in the future of solution architecture, by vice-president and principal analyst Randy Heffner.
