Want to read more on how enterprise teams scale with microservices? Read the full eBook on “How to Build (and Scale) with Microservices” here!
In the last few weeks, we’ve introduced the concept of microservices and its role as a business initiative and how to migrate your organization towards a microservices model. Transitioning to microservices creates significant challenges for organizations. This week, I’ll delve into some of the obstacles you might face and the ultimate benefits of your efforts.
Microservices Architecture
Microservices architecture is much more complex than legacy systems. In turn, the environment becomes more complicated because teams have to manage and support many moving parts. Some of the things you must be concerned about include:
- As you add more microservices, you have to be sure they can scale together. More granularity means more moving parts which increases complexity.
- When more services are interacting, you increase possible failure points. Smart developers stay one step ahead and plan for failure.
- Transitioning functions of a monolithic app to microservices creates many small components that constantly communicate. Tracing performance problems across tiers for a single business transaction can be difficult. This can be handled by correlating calls with a variety of methods including custom headers, tokens or IDs.
- Traditional logging is ineffective because microservices are stateless, distributed and independent — you would produce too many logs to easily locate a problem. Logging must be able to correlate events across several platforms.
Other considerations to take include:
- Operations and Infrastructure: The development group has to work closer with operations more than ever before. Otherwise, things will spin out of control due to the multitude of operations going on at once.
- Support: It is significantly harder to support and maintain a microservices setup than a monolithic app. Each one may be made from a wide variety of frameworks and languages. The infinite complexities of support influence decisions on adding services. If a team member wants to create a new service in an esoteric language, it impacts the whole team because they have to make sure it can work with the existing setup.
- Monitoring: When you add additional new services, your ability to maintain and configure monitoring for them becomes a challenge. You will have to lean on automation to make sure monitoring can keep up with the changes in the scale of services.
- Security of Application: The proliferation of services in this architecture creates more soft targets for hackers, crackers and criminals. With a variety of operating systems, frameworks and languages to keep track of, the security group has their hands full making sure the system is not vulnerable.
- Requests: One way to send data between services is using request headers. Request headers can contain details like authentication that ultimately reduce the number of requests you need to make. However, when this is happening across a myriad of services, it can increase the need for coordination with members of other teams.
- Caching: Caching helps reduce the number of requests you’ll need to make. Caching requests that involve a multitude of services can grow complicated quickly, necessitating communication from different services and their development teams.
- Fault Tolerance: The watchword with microservices is “interdependence.” Services have to be able to withstand outright failures and inexplicable timeouts. Failures can multiply quickly, creating a cascading effect through some services, potentially spiking services needlessly. Fault tolerance in this environment is much more complicated than a monolithic system.
Spotlight on DevOps
In an old-school development environment, there was little integration of the separate functions within the operation of the IT department. DevOps is the evolution of collaboration where the operations, development and quality assurance teams collaborate and communicate throughout the software development process. It’s not separate role held by a single person or group of individuals. Rather, it conceptualizes the structure needed to help operations and development work closely together. With a microservices architecture, developers are responsible for creating a system to deliver the final product successfully.
Along with the continuing migration of large and small organizations to microservices, developers must also evolve. Because it is so easy to deploy microservices, developers are getting involved in code deployments and production monitoring. This contrasts with the traditional instance where developers would write code and hand it off for another team (DevOps) to deploy and maintain. Today, developers and DevOps are merging into smaller application teams responsible for three main components: building, deployment and monitoring.
Microservices are changing how teams are structured, allowing organizations to create teams centered on specific services and giving them autonomy and responsibility in a constrained area. This approach lets the company rapidly adjust in response to fluctuating business demand, without interrupting core activities. It also makes it easier to onboard new staff quickly.
Developers may have to handle some additional challenges including:
- A shortage of developers with JavaScript experience that know how to put together microservices architectures.
- Understanding and implementing services for the Internet of Things.
- The ability to help companies introduce technology into business planning and strategy.
- Teaching business leaders how open APIs can augment their current business lines and open new opportunities in the marketplace.
- How to simplify the development stack, choose the right technology and push back when vendors offer unproductive middleware.
- Learn from industry leaders like Netflix, and decide which implementations of microservices will best serve their organizations.
- Understand that many vendors have still not created a stable microservices platform.
- Be able to handle the pressure of managing and operating possibly hundreds of individual microservices at the same time.
- Manage an increasingly complex network of teams including operations, architects, coders, quality assurance and integrators that still may not completely understand the microservices approach.
Beginning the Transition
Once you launch the transition process, you’ll notice that new challenges emerge that you did not expect, including:
- How much of the workload should be moved to microservices?
- Should you allow code to be migrated to different services?
- How do you decide what the boundaries of each microservice will be while the operation is running?
- How do you monitor the performance of microservices?
Want to read more on how enterprise teams scale with microservices? Read the full eBook on “How to Build (and Scale) with Microservices” here!
| Reference: | 4 Challenges You Need to Address with Microservices Adoption from our JCG partner Saba Anees at the AppDynamics blog. |
