Claus Nielsen is adamant that when managed correctly, microservices can be the agile remedy to the complex, monolithic architectures that often drain time and energy from companies and their employees.
For at least a decade, microservices have been evangelized by Neural Technologies and Nielsen who is the company’s Director of Product Management. This stretches back to before they even referred to them as microservices (“botpac” they called them – a combination of robot and package).
Microservices architectures break the application-building process down into components – small, loosely coupled, autonomous components (meaning they have the freedom to act independently) – that can then be reassembled to deliver larger applications. Neural Technologies combines microservices to build platforms for others, or provides microservices to partners who prefer to develop their own solutions.
AM: Give us a brief idea about what you’ll be discussing at the event.
I’m planning to talk about how we’ve [Neural Technologies] been utilizing microservices to develop solutions on top of our platform, and about why it’s the best way to develop. We’ve been doing it since 2003 and I want to explain why it makes sense that the industry adopts microservices as best practice. I’ll also be explaining some of the potential pitfalls so that people and companies don’t get caught out when they’re trying to adopt microservices themselves.
AM: Why do you use microservices and what are the advantages?
I’ll use the analogy of cars to explain why we adopted this methodology. We took the approach that the car industry does when it’s manufacturing vehicles. The car assembly robots that put the cars together and paint them etc. can all be adapted to the unique styles and sizes of vehicle. In the same way, microservices that are a part of an end-to-end solution can simply be plucked out for use in any new software. Users wouldn’t need to deal with any partners, untangle a complex architecture or build an entirely new product. Furthermore, if microservices need fixing or further development, this can be done independently while the rest of the systems carry on as usual.
The time to market is another a definite advantage of using microservices. As it can be hard to develop customized solutions for clients, the ‘plug and play’ advantage (taking the microservice from the old solution and using it in the new one) means they can launch new services and solutions more frequently. They save time because the standardized APIs and common orchestration mean they’re written to fit into the new service, work the way they need to and do exactly what they say on the box.
As development time affects price (companies often use timestamps to price their solutions), the less time taken means companies can be more competitive with their pricing. What’s more, this efficiency and bigger margin mean more time and money are freed up to focus on developing or improving other areas of the business.
AM: What are some of the challenges the industry faces in adopting microservices?
Companies need common orchestration systems. If you think about an orchestra, the guy with the stick [the conductor]is making the trumpets and the drums and everything else work together to play the song in harmony – this way, the song sounds how it should and the musicians know how and when to play their instruments. In the same way, when the individual microservices come together to create the total solution, the orchestration layer (from orchestration software) can make sure that they work in harmony.
The biggest adoption mistake is to have no common orchestration or methodology. When microservices finally come together, there will be mismatches without orchestration. The different departments in a company who want to focus on developing various parts of the network must choose vendors that have a framework suited to their adopted common orchestration.
Another challenge is complying with any rules and regulations that can affect microservices. The challenges for data governance for example; in Europe, the imminent General Data Protection Regulation (GDPR) means anyone utilizing and developing microservices will need to take into strict consideration how data is exposed/share/stored through APIs or locally, and how that data is managed. Microservices data management if you will.
How big a part do APIs play?
A microservices architecture relies on APIs to make one microservice available to another within an application.
Exposing a common set of standardized APIs per microservice means the user use the microservice without any help from the developer, without having to build in the microservice as part of the overall solution and can tailor the APIs to fit the specific needs of the solution.
Users can also adapt their standardized APIs to governance policies (security, auditing, dynamic data filtering, etc.) by adapting the permissions to align with the necessary policies.
Finally, users can monitor their standardized APIs’ traffic levels and usage patterns and change/improve/scale the microservice without having to change the entire solution.
How can companies best manage microservices?
It all comes down to the orchestration as I talked about earlier. With that, they need to have very well thought out dynamic workflows so they can very quickly pluck in new components and configure them to develop their ‘song’. They also need a certain set of strict rules imposed on the microservice – what it can be used for, which APIs it can be exposed through. Post-deployment, each individual microservice should have its own roadmap for how it can evolve and become more effective. When these microservices do evolve, any solutions already using the previous editions can take full advantage of the new version.