You might have heard someone drop ‘microservices’ as a buzzword in a meeting. Perhaps your technical team has mentioned them, but you are not really across what they are, the business benefits, or why you need them.
Microservices may seem like a mind-bending concept at first, but once we break them down into their core purpose and what they deliver for a business, they become pretty straightforward.
AWS said it best in their simple overview…
‘Microservices are an architectural and organisational approach to software development, where software is composed of small independent services that communicate over well-defined APIs.’
These small independent services are utilised through orchestration (and yes, you can think of an orchestra and a conductor to understand what orchestration is) to deliver a much bigger piece of functionality, but they operate independently of each other.
To put it another way, microservices are an architectural style that structures an application (such as an online accounting package or a social media platform) as a collection of services that are:
- Loosely coupled
- Independently deployable
- Organised around business capabilities
- Owned by a small team
- Highly maintainable and testable
Microservices are a way to break down large applications into smaller sub-components of functionality. For instance, when uploading a new photo to Facebook, there are multiple microservices performing in the background, to provide you with one seamless upload experience:
- The image uploader handles the actual receiving of the image and moving it to a location for public access over the internet
- An AI image recognition service scans the image to make sure it does not contain inappropriate imagery
- A tagging service allows you to tag others or apply a comment to the photo
- An image conversion engine optimizes the photo for faster viewing on various mobile devices
All the above processes work together to provide an outcome (i.e. your photo is made available for your friends to see), and this is done in a fast, flexible way. To briefly demonstrate the ‘independence’ of each microservice, let’s think about the tagging service within this example:
If the tagging service needs improvement, the team that owns that particular service can make those improvements and deploy a newer version of the tagging service without it affecting any of the other services, which gives their business model a clever way of having independent teams all contributing to a better overall product, without stepping on each other’s toes (figuratively).
By contrast, a program written 20+ years ago would have taken a monolithic approach to software development. The code in a monolithic application is written as one very large program, with many moving parts. I won’t go into the reasons why they were done this way, but it made the most sense at the time - especially before the internet. The big problem we face for the monolithic way of building applications is in the difficulty to change (fix or enhance) the application if one part breaks, or no longer serves a valid purpose.
Microservices can simplify development, testing, and deployment. They make it easier for your company to experiment with new features and allow your technical teams to enhance different parts of your application without disrupting any other parts.
Microservices will guide the way forward for monolithic applications
Developers created microservices as a new approach to an age-old business problem. If we look at this from the macro level, stepping back from just a single application and looking at all the operations within a business, we see the same pattern and problem. In the past, you might have leveraged a few complex systems that each managed many different roles across the organisation (such as finance, accounting, inventory, warehouse, communications). Microservices deliver smaller systems that you piece together (like a jigsaw puzzle) to complete the solution for each area of your business.
The benefit of leveraging microservices in this instance is that you can take the best functionality from each system without locking into a single vendor not entirely aligned with your needs. The microservices approach to software allows you to choose products that support your business without paying for extra functionality that you do not use.
Once you understand the basics of how microservices work, it seems completely obvious that this approach is much easier to use if you were starting a new business or creating a new application now. But what about existing applications that took years to build?
For software development companies, switching to a microservices approach to delivering software is not simple. With years of existing code already in place (both in terms of the IP that is represented and all the customers who are currently using it), you cannot just switch one-off and turn another on. They need to still support all those existing services (written with a monolithic approach), fix bugs and give them new features. All the while, you can bet that they see the advantage of taking a microservices conceptual approach to software delivery. The option many of these businesses will take will be a combined approach, mixing the old and the new, by:
- Utilising a large core piece of existing software (built with a monolithic architecture), containing much of the IP and primary functionality of their software
- Building an interface to allow the existing core to communicate with microservices (via APIs)
- Then introducing new functionality/features (using microservices) as extensions to the existing core
- Whilst slowly replacing older parts of the core with newer, better functionality in the form of microservices
In a similar conundrum to the above, businesses wanting to introduce microservices into their businesses will face the same type of problems. They cannot just turn the old programs off.
As they are being introduced into existing businesses, microservices will be used to supplement existing functionality for a time. The mixed environment approach of monolithic and microservice architectures will stay around for some time, as IT departments who see the need for flexibility slowly work out how to make that change happen as painlessly as possible to the business. The idea of a simple switchover (especially for medium to large businesses) is almost impossible without a lot of money and time to prep.
The companies that will be able to adopt a pure microservices approach immediately are those that are starting from scratch.
Cloud computing and APIs support microservices
Microservices are not a recent, groundbreaking invention. They’ve been around for a long time, and were previously known as service-oriented architecture (SOA). They are rising in prevalence because better ways to leverage them have emerged.
Cloud computing provides microservices with the scalability, reliability, and security needed. The cloud is an ideal place to leverage microservices because you can easily scale up or down depending on the demands in your business. As more businesses adopt cloud services, they have more microservices to choose from.
It is important to note that cloud computing is not solely responsible for the increased accessibility of microservices. The cloud has just provided new methods for developers to build and deploy the functionality they need in their applications. You might have heard of the sharing economy. It’s true for applications as well. Developers don’t need to build every function into their own application, instead, they can reach out to other applications and use that functionality if/when required. This is one very common use case of microservices.
Application programming interfaces (APIs) are the way microservices connect to each other. As API functionality has become more lightweight, prevalent, and faster, they have opened up more possibilities to utilise the microservices approach.
Optimise your costs with microservices
Applications built with microservices are often cheaper to run than monoliths because they follow a pay-per-usage model. For small to medium businesses, this is much better than locking in a costly, multi-year contract with one company.
Additionally, microservices make it easy to scale your application up or down as needed. You can simply add more microservices to your application if you need more functionality. If you need less functionality, you can remove the microservices you do not need. Such agility allows you to eliminate unnecessary costs.
It’s fair to say that it’s not as easy as just turning functionality on and off. Making this seem easy only happens with people who’ve got a lot of experience in this domain.
In addition, when one microservice fails, it does not take the rest of the application down with it. The failed service may not be critical to the whole application, and it may be able to resume working (and even catch up) once it becomes available again. This is due to one aspect of the microservice architecture which dictates loosely coupled functionality. The advantage of greater application resilience and reduction of potential revenue loss during an outage is easy to imagine.
Microservices often only require a small team of developers for each service, rather than a large IT organisation. Small teams, where each person(s) manages their own microservices, can be more effective at fixing issues or deploying updates. When developers have to fix small issues on a monolithic application, it can take a considerable amount of time and money.
Challenges created by microservices
While microservices offer many advantages, they also come with their own set of challenges that impact how successfully you leverage them. Challenges you should be mindful of include:
The complexity has moved from a monolithic architecture
Each microservice is smaller and simpler than a traditional monolithic application, but the orchestration of all these services (to form the greater application’s suite of functionality) can be difficult to manage and monitor. As your system grows, the complexity only increases.
Microservices require better service management
Microservices can improve the agility (and time-to-market) of an application. However, they also create greater complexity of the interactions between services and thus require better service management. Because the application comprises numerous parts, your service management team must work both collaboratively and independently (yes I realise that’s confusing). There are programs built specifically to help this challenge when it gets too big - they are referred to as a ‘service mesh’.
Uncoordinated adoption
Problems arise when multiple application development teams attempt to adopt the microservice architecture without any coordination (or strategy). This can mean that the objectives of each microservice, the patterns of architecture, and the deployment and testing practices are misaligned. When that happens, the ideal scenario becomes a nightmare scenario for the teams (and systems) that are meant to be utilising these services.
What you need to consider before implementing microservices
A company looking to implement microservices effectively needs to realise this…
You don’t just implement microservices, you adopt them as an approach. Microservices are not something you can just turn on one day, it’s an architectural concept that needs time to be understood and integrated within your organisation. So, you need to understand what you’re trying to achieve and why. Then you might be able to solve that ‘what’ and ‘why’ through the ‘how’ of microservices.
As a quick guide before going any further, ensure that:
- You understand what you want to achieve
- You have a strategy of the big picture and this is communicated clearly to all stakeholders (going down this path changes your architectural design forever)
- You have a clear understanding of what functionality is available (within the existing microservices landscape) and what you will need to develop from scratch
- You have a step by step approach for your early implementations
- You start small and be incremental with your improvements - that’s the whole point, there is no need for a big bang approach
- You are prepared for some initial growing pains as your technical teams get familiar with a new way of designing, deploying and communicating functional change
Microservices are a very powerful way of improving your business processes/operations/services, but they can also introduce a lot of complexity, and be extremely difficult to manage, even if you do have the right skills within your team.
Hopefully, after all that, you feel like the topic of microservices is a little less of a daunting concept. It is not an overly complex concept to understand, but it does take a different mindset to adopt within your organisation and not every IT department will have those skills right now. Do plenty of research and speak to people who have been down this road before.
Creative Folks can become your technical team
When we work with customers who need their systems talking to each other, we look at their applications and the underlying services these applications have to offer. Our expertise lies in understanding your ecosystem, highlighting the possibilities, presenting your options and deploying the right solution for you.
Visit our Systems Integration page for more on our capabilities.
Previous
