If Microservices weren't the answer then Design Patterns have the solution.
Submitted by Ent (@last-ent) on Friday, 4 August 2017
Technical level: Intermediate Status: Submitted
Microservices are the trend now. However, they are not always the right solution and in hindsight, some services should be merged/combined. What’s the proper approach? Design Patterns have you covered! I feel this is quite a common problem we face and this talk will be insightful on how to solve it.
Microservices. Right now they are somewhere between the Trough of Disillusionment & Slope of Enlightenment in the Hype Cycle.
Few reasons you might want to merge a few of your Microservices:
The complexity inherent in Microservices is not worth the cost. You had to split a service into microservices due to constraints and now those constraints are removed. GOTO #1.
In one of my projects, I ended up with #2 and this talk is about how I had to engineer a solution where the two services were combined into one and yet, I had to take care to ensure that they were decoupled enough to let me split them into microservices if the need arises.
Turns out, this is a common problem that spans beyond Microservices and Design Patterns already provides us with ideas on how to solve it.
Planned Talking Points
Microservices & the Hype Cycle
Brief discussion about what are microservices and where it stands in the Hype Cycle
(Sometimes) Microservices considered harmful
These aren’t Microservices! No more technical constraints
Refactoring: Microcosm & Macrocosm
Duplicate functionality & Refactoring What are Design Patterns? Design Patterns that might help.
Did it work? Unexpected Challenges
I am a software web backend developer with over 10 years of experience where I have worked with many startups. I have worked on multiple domains from physics simulation models to Ad Tech. I also love to tinker with technologies to better my understanding of our field.
This talk is based on my experience around two services I was maintaining, one was located in the Data Center and other on AWS. The reason for being on Data Center was because we needed it to communicate with another Data Center specific service. Once the Data Center specific service was shut down, for cost & convenience reasons, it made sense to merge these two services into a singular service. I feel this is an important topic that should be covered in detail and hence my proposal for the talk.