Microservices offer many benefits: Low coupling, high cohesion, low “blast radius” when something goes wrong, and, most importantly, developer productivity. Akka is VERY well suited developing microservices – Akka’s message based approach steers developers in a direction that encourages thinking in terms of messages, and also provides asynchronous processing. All that, and it’s pretty fun too.
But.. what about the monolithic application that needs to become a set of microservices? A large, “mature” codebase that has been developed with “microservice hostile” patterns can be challenging to decompose into microservices. How big should they be? What’s the process to make an in-flight transition to microservices , keeping the low(er) operational burden of a monolith, while making good progress towards decomposition into microservices? Is there an iterative path from monolith -> microservices?
And, for Ops, it’s often – “eh, not so much”, as Microservices create operational sharding (the bad kind, like a broken sheet of glass). How does the transition work? Where do we look when “stuff is broken”? Which VM? Where are the metrics?!
This talk will be presented as a case study of the Comcast internal project, Gumby. Gumby is a cloud deployment tool, that is used, among other things, to deploy the national X1 server infrastructure. Gumby is a Scala/Akka/Spray app, and has evolved over about 4 years from a Play! app to it’s current incarnation as a Spray/Akka set of Microservices. Our team has had to grapple with all of the above issues (and many more) and we’ve learned a few things along the way.
I’ve been a developer for 22+ years, working the majority of that time in Java. With experience in a diverse spectrum of problem domains, including blood transfusion, enterprise SAN/network management and payment systems. I’ve had a lot of opportunities to learn from my mistakes.
I’ve been very fortunate to be able to work in Scala for the last 3 years or so, in the service of Comcast, where I have been for about 6 years. I’m currently a developer on Comcast’s cloud scaling tool, Gumby, where I’m on a great team, writing interesting software while we do our best to be as “DevOps” as possible. I am based in California, and work out of the Comcast Silicon Valley office.