Source: devprojournal.com
Microservices architecture adoption has moved beyond use in the largest of cloud enterprises to applications of all sizes. Whether you are an early adopter – or you’re just now weighing your options — Kyle Davis, Head of Developer Advocacy, and Loris Cro, Developer Advocacy Manager at Redis Labs, authors of Redis Microservices for Dummies, share their views on the state of microservices and what developers need to consider before transitioning from monolithic architecture.
How are microservices evolving after the first wave of adopters have had them in production?
Cro: Wider adoption of microservices has consolidated best practices and produced a new set of tools at the disposal of software engineers. One big example is the union of microservices with the Event Sourcing pattern, where the main source of truth of a service is represented by an immutable log of events, which is quickly becoming a standard practice in the industry. Another important result of the first wave of adoption is that we can now say with certainty that the microservice architecture requires considerable software engineering know-how from companies attempting to implement it, at the risk of causing the whole transition to fail. In simpler terms, we now know that you have to be “this tall” to use microservices.
Davis: As with anything new and high profile, the industry is adapting to find the right balance. Truly, the microservices architecture is one choice among many that has to be decided based on several (organizational, technical) factors — it’s not one size fits all. For those that find the right fit, it is transformational. For those that are ill-suited, it becomes extraneous. So, the first wave blazed this trail and has provided both stories from the trenches and stories from nirvana. Even those that the architecture helps them produce better software more rapidly often see new challenges vs. monolithic architectures, such as latency that need remedy, and the industry is now seeking out solutions higher on the hierarchy of needs.
What is driving microservices growth?
Cro: To best understand microservices growth, it’s easiest to look at the problems of its alternative: the monolithic architecture. In a monolithic architecture, everything is contained in one unit. This means that when something breaks, as even the best software sometimes does, it breaks as a whole. Additional problems arise when you try to scale, install updates, and add new releases — making the overall process slow and painful. On the other hand, services are simply easier to build and manage than monoliths. The microservices architecture isolates complexity, allowing for smaller, more agile teams to create a service. So, as companies continue to scale at rapid rates and technology continues to become inherently more complex, microservices provide the assured agility and stability monoliths cannot.
What are the benefits to end users?
Cro: The real benefit that end users get from microservices consists entirely of a chance at a better user experience. Microservices are just an architectural pattern that allows engineers to build products at a lower overall cost. It’s clear that when an organization loses control of a system, end users will be impacted in terms of performance issues, bugs and general unpleasantness, while on the other hand, when a team is in full control, it has the opportunity of polishing any rough corner of the product. So, while the microservices architecture doesn’t offer any direct advantage for the end user, it does work as a catalyst for improving engineering projects by making them easier to create and scale. As an example, being able to use different languages and database systems on a per-service level allows development teams to choose the right tool for the job more easily than it would be in a monolithic application. This is one of the many ways in which microservices help teams produce better applications.
Davis: Hopefully, the end user would never have any clue that a product is based on the microservices architecture. What they would notice is a more rapid and adaptive pace of change on the service. In that way, the needs of the end user can be met over a shorter period of time and with less disruption.
What are the benefits and drawbacks for developers?
Cro: Microservices, when correctly implemented, offer developers flexibility, versatility and scalability, allowing them to build and maintain incredibly intricate systems at a lower cost and a higher efficiency. With the ability to implement a wide range of individual services, developers can then leverage a wide range of languages, technologies, and third-party applications. Thereby, should a service require a newer technology (or one from a different vendor), developers are no longer locked-in to just one vendor or technology. And, with a microservices architecture, a project is able to evolve more naturally, adopting the industry’s new technologies and embracing the community’s new solutions at ease.
However, by design, these systems are inherently more complex, with each independent service necessitating its own specialized attention and maintenance. Now, services are distributed, making global testing more complicated; the services’ suite is more intricate, necessitating a highly-educated, well-versed team to maintain it; and communications not only between the services, but the ground rules for microservices must be kept strictly maintained. Any changes in how services communicate requires careful, deliberative change management. When considering microservices, it is important to be mindful of what capabilities your team has, their bandwidth, and the goals and eventual scale of the system itself.
How are microservices evolving now that they are scaling?
Cro: Now that organizations know how to approach the development of a microservices architecture, they are introducing new concepts that would be very hard to add to existing monolithic applications. One example of this is Conflict-free Replicated Data Types (CRDTs), which allow creating geo-distributed multi-master database clusters where all masters can accept writes and synchronize even in the face of network failures. This creates a new class of strong, eventually consistent systems that behave much more efficiently than quorum-based ones. The result for the end user is that every operation implemented on top of CRDTs will have local latencies, regardless of where the user is situated in the world (assuming there is a local master to send the operations to).
Davis: As the scale-out of services continues, previous roadblocks have been opened up by deploying more instances of the same service. This creates new challenges; as an example, the underlying database needs to be able to handle more connections than in some monolithic architectures. Developers and architects need to think about using the best tools (languages, data models) for the job at hand, and services can now make these leaps without creating full organizational chaos as would happen with monolithic apps.
Many enterprises have held off and are just taking this journey, what can they learn and benefit from in making this move now?
Cro: Committing to making the transition from monolith to microservices is not something to take lightly. It requires thoughtful planning and consideration, a flexible budget, and an experienced team. However, as more and more companies embark on their digital transformation — scaling up, out, and beyond — establishing a microservices architecture early on will save the pain, time, and cost of making the migration. While the process will be consuming, with the ever-growing number of developers and enterprises adopting the microservices architecture, you will have a community to lean on and learn from (and, as every developer knows, that’s the key to survival).
Davis: Now is a great time as the microservices architecture has marched from something less common to something that is well understood. Additionally, more software is being built with supporting microservices specifically in mind. Small changes and yield big improvements — even support for conceptual acknowledgment groups over streams makes the architecture much more straight-forward to implement.
What is your advice for software developers and ISVs regarding microservices?
Cro: In the case of microservices, the structure of your teams must mirror the structure of your system. Microservices emerged from DevOps practices of companies like Facebook, Google, and Amazon. This is because DevOps practices reiterate the operating ideology of microservice (break large problems into smaller, more manageable pieces) and promote a culture of collaboration and automation. If your teams are already leveraging DevOps, adopting microservices will be a natural fit. If not, we strongly suggest adopting a DevOps culture before beginning the migration.
Once you’ve got your teams structured, choose the right database. Slow databases don’t work in a microservices architecture. A microservices architecture is made up of many individual parts that communicate with one another, and the individual services should be stateless. The nontrivial bottleneck in this architecture is a slow database.
Davis: Step back from previous problem-solving approaches, and think about what parts of the organization own a process and the underlying data and focus on the interfaces between processes. This isolates complexity for each problem. Whereas a single problem may require coordination between many parts of the organization, each individual service has to only maintain the data it needs and solves smaller problems. The smaller the problems and less data you need to maintain means that each service is a smaller, more approachable problem.
