RESOURCES
Abstract/Description
DevOps can help you dig out of the problem you created for yourself: you spent your lunch period reading the interwebs, drank the kool-aid, and decided to embrace the utopia of microservices to solve all your fragile legacy monolithic code issues and allow you to release small independent changes into production. What you didn’t realize is that you’ve translated an early-lifecycle code architecture problem into a late-lifecycle release management and quality assessment nightmare.
This microservice thing has not provided the nirvana you expected. You ended up with a set of federated services that have hidden dependencies on each other. You have a bucket full of independently changing applications maintained by teams that don’t talk to each other and hide behind their service APIs. You want to deploy changes to production, but you can’t even figure out which versions work together in your test environments. You need a way to bring your teams closer, continuously integrate the services, deploy the integrated services into various environments, and test that your still-monolithic system works in pieces and as a whole. This is looking suspiciously like a DevOps problem. You discover that your DevOps pipeline is critical to your success.
Someone once said to me “if you are building microservices without DevOps, you’ve already failed.” I’ve learned that the integration problems created by independent microservices require a high level of automation for build, deployment, testing, and release. You need to create an automated pipeline that works independently for the individual services, yet has enough global knowledge of the system to assess whether small local changes break other services. The pipeline needs to facilitate communication between teams and notify them BEFORE they hopelessly break the system. It needs to keep track of which versions of the services include the right fixes to mutually breaking changes so they can travel together toward production.
In this talk, I highlight the important things you need to succeed with microservices and avoid some of the common problems:
* Patterns for individual pipelines that combine to assess a working system
* Using dynamic, ephemeral environments for early cross-service testing BEFORE people break things
* Determining how appropriate versioning can simplify releases
* Establishing a branch/merge process to minimize integration problems
* Determining the value of using containers vs. virtual machines for microservices
* Enumerating the types of testing needed at different stages of the pipeline
Participants will leave with some new ideas on what they might be doing wrong in their current microservice-based project and/or anticipate what’s going to go wrong if they are just getting started.
You must be a Member to view this post and you are currently not logged in.
You can either log in below or sign up here.