Search This Blog

Loading...

18 April 2015

Microservices for the rest of us.



Microservices: An Accessible Overview

By Kelsey van Haaster

If your work were remotely associated with software development, it would have been difficult for you to miss the recent excitement and discussion in the tech world about the term Microservices. Much of this discussion has been in the context of the underlying tech, software architectures, development techniques and cloud-based services. The conversation has been conducted mostly within technical forums, blogs and meet-ups. As a consequence, you may have felt that this was a purely technical discussion of little relevance to your work, or you may have been put off engaging in the discussion because you don’t identify yourself as sufficiently technical. Neither of these things is correct, this is not only about gnarly tech stuff and you don’t need to be a gnarly (or not) tech person to engage in the discussion, so read on and join the conversation.


What does the term Microservices mean?
To the non-tech person, when the tech folk are talking about microservices they are referring to a way of thinking about how software (usually) services are architected, created and delivered. It’s not about a particular tool set, or package and doesn’t require a specific skill set.  Using a Microservices approach to strategic delivery has both practical and strategic implications the whole IT team, including business analysts, project managers, product managers.

What is a Microservice?

It’s probably easier to start off with a description of what a microservice is not.

We are all familiar with the concept of a big enterprise system that does everything, for example, ERP systems, like SAP, or CRM systems such as Salesforce.  These kinds of applications are called monoliths, they are a one stop shop for a whole lot of different things and have the goal of standardising things, such as how data is managed and how things travel through workflows and processes. This results in a lot of very complex data transformations going on.  These monolithic applications are often supported by a central data warehouse, a repository for massive amounts of corporate data, which is processed and repackaged so that it can be used for various things, e.g. monolithic applications or to support financial reporting, or data mining.

These things are not microservices!

A microservice is a self-contained system that is designed to do one thing really well. Taking a microservices approach to systems architecture means building multiple microservices to provide the various functions needed by a business.  

Cross-functional teams focused on building a product, which meets a specific business need, rather than a general one, develop Microservices. The idea being that the same team will develop and maintain the microservice throughout its lifespan. Microservices are as self-contained and decoupled as possible from other services or applications. Microservices are designed to be smart enough to do all their own data processing so using multiple microservices to do different things avoids the need to create complex interfaces between them.

What are the benefits of microservices?

The main benefits of microservice approaches are found in reduced dependency between systems and therefore reduced risk associated with change. Many of the monolithic applications mentioned earlier require very specialised skills to manage and maintain them. They represent silos of knowledge in the business and when one of them has a problem, the amount of inherent coupling they imply can bring everything to a grinding halt. These monolithic systems are also expensive and difficult to implement, (anyone recall their last ERP project). For smaller organisations, the size and cost of these systems can be a significant barrier to implementing them.

Because of the decoupled nature of microservices, you can do some pretty cool tech things that can save a lot of time and money too. For example, you could develop a microservice to receive data from multiple sources by email, process it and make the published data available for report generation. You can develop your microservice in such a way that it is triggered only by the arrival of new data. This kind of thing has important implications for both small and large organisations. Large organisations could employ this kind of strategy multiple times to meet specific reporting needs. Multiple targeted, self-contained and minimally coupled services can reduce the costs, overheads and bottlenecks associated with maintaining central data processing and reporting functions.  For smaller organisations, microservices can provide a lower cost, lower risk way to develop and deploy services.  

Implications for the BA/PM

The decoupled, flexible and independent nature of a project using a microservices approach means that the BA and PM may be able to spend less time managing complex stakeholder relationships around the external interfaces of the project. Microservices are small systems, that do one thing, this means that the stakeholder group may be smaller and more aligned. Tighter scope, small teams and small stakeholder groups support continuous discovery, development, and feedback. What’s not to like?

For those who want to read a more detailed description the following is a good start: