Microservices: An Accessible Overview
By Kelsey van HaasterIf 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:
No comments:
Post a comment