Microservices— Are they worth it?
Microservices are here to stay, but when do you go micro or monolithic?
Microservices are a popular choice for firms looking to speed up delivery and time to market. However, problems — and costs — arise when automation and back-end systems are not maintained.
We joined technology consultancy Synechron to hear their discussion on when microservices are worth it and how best to implement them. Answer: Understanding the use case is critical, as monolithic solutions can work just fine. Here’s what we learnt.
Performance is everything
During the pandemic, Amazon Prime refactored its microservices approach. Why? Because it hadn't considered how the application would perform in a high-traffic environment. Simply put, it didn't. They decided on a monolithic approach, rationalising and designing a single service and reducing cost.
Why this matters: Be smart and take a top-down approach to understand when and how microservices should be applied.
Keeping up with the competition
Open banking — the ability to share, with consent, customer insight depending on the service’s purpose — has made microservices architecture a must-have.
Large banks compete with neo-banks. However, their data is distributed, so when digitisation started ten years ago, firms opted to put a wrapper on legacy applications, the quickest way to market—the result: good front end, shocking back end.
This created a profound technical debt because of compliance and security regulations and budget constraints, as 85% was allocated to maintaining the old system.
“Medium-sized organisations can have 4000 plus micro service applications. ”
Why this matters: How do you develop a green field-type strategy? For any new product innovation and microservices, make new applications cloud-based. For legacy applications, stay as-is and modernise.
Chatty microservices
Data services and systems must be integrated, but how microservices talk to one another is pivotal to strategy.
One watch out was a case study on digital modularity, where the business goal was to create isolation in deployment. Microservices increased to 50+, and costs became prohibitive. In addition, the shared library had problems updating because of the system. A separate library was created, but it created versioning issues. In 2018, the business went back to monolithic architecture.
Why this matters: Flexibility is not enough without a view of scalability and a vision of how these services grow individually and interdependently.
Bite-sized, independently connected chunks
Another case study involves a bank trying to onboard new processing payment solutions using APIs. The bank decided to fix the microservices application because it required a lot of implementation and because it was afraid that one line of code would break everything else.
One transaction can involve up to 14 parties. They broke down applications into smaller chunks to move smartly and isolated one microservice at a time. This required identifying what was core to the primary service and could be standalone, e.g., items not needed for every transaction, such as currency exchange.
Why this matters: Every microservice should be independent and have its own database. If two services are always talking to each other, don't break them. Technology has matured, and using cloud-based services helps with performance.
Challenges when designing microservices
1. Model
One firm moved from a monolithic to micro-modularised technology and service architecture. However, in deployment, services were slower, and changes were complex. Microservices were meant to solve it, but they created them. This is common when services are too chatty or if one change affects many other services and shared databases.
Why this matters: Don't be mistaken for optimising in the short term and removing the benefits microservices are meant to provide. If you are in this trap, live with it or return to the monolithic model.
2. Hidden costs
Microservices can result in costs and slow things down. Not all microservices fit all cloud providers, meaning deployment and operations can be hidden.
Why this matters: It is essential to understand the benefits and issues.
3. Scalability and visibility to NFRs
Organisations have to consider horizontal and vertical scalability (Vertical, e.g. CPU; horizontal, e.g., new instances). This can be complex and requires balancing traffic versus creating a consistent experience.
Firms need to process data within an acceptable response time, which is hard when it’s not always clear what's coming. Monitoring logs can help with this.
Why this matters: You need a synchronised first approach. This means investing in efficient orchestration, e.g., a good distributed tracing mechanism, which is easier when applications are on multi-clouds like Google or Azure.
Microservices checklist
Good container orchestration
Service architecture. e.g. Google or Asure
Multi-cloud strategy
Libraries and patterns
Real-time monitoring tools, e.g., Jaguar log metrics and tracing, even if they are automated.
Management tools, e.g. to improve pipelines
The future
The focus has been on the technology, which will continue to drive change, especially with AI and ML gaining momentum. However, in the future, culture and business benefits (and cons) must be front and centre. To support the change, the experts recommend gaining business insight into applications by making data gathering fast and visual.
