At Yucca Labs, we used to combine Product Line engineering and Service-oriented computing in order to build platforms that evolve well over time along with market changes.
Keeping focused on the product while its functional scope is getting bigger requires a strong ability to provide a relevant design that ease,
- The integration of new features
- The proper use of technologies
- The deployment & integration processes
- The testing
- The new developers onboarding
Microservices as a design pattern,
Microservices approaches in theory look very promising but they require taking into account shifts and requirements that are very specific to the problem you’re trying to solve in order to be properly implemented.
Microservices require splitting your application into multiple small services that you can deploy and scale individually. Taking advantage of various sets of technologies and languages.
It also helps you perform a faster release and cycle based on very targeted deployments.
The devil of Microservices
Purist approaches end up getting stuck on drawbacks most of the time. The complexity pure microservices techniques introduce are very hard to tackle;
- interactions between services rely on network calls that can and will fail.
- Debugging a microservices solution can become a nightmare.
As an example, let’s say we’ve to build a solution to manage a football league. A pure Microservices approach advice us to design 3 well decoupled services as follow,
- A dedicated microservices for leagues
- One for teams
- One for players
And probably an extra microservices that manage the league’s calendar.
Taken separately, these microservices don’t provide functionally consistent data.
A league consists of a set of teams and a team mainly contains a number of players. eams
Gathering information on a league or a team consists of loading teams and players.
We always need to aggregate data issues from +1 microservices in order to serve our clients requests.
Each time a microservices evolves you’ll need to upgrade the consumers (clients app).
A Gateway API to aggregate data …
Aggregation here could be performed by a lightweight gateway API put on top of your microservices layer in order to serve the client apps (web or mobile)
We perform at least 3 network calls for every request which could be improved if we rethink the design differently.
Here comes The Hybrid approach …
Why don’t we put the league, team, player within an aggregate service or Gateway API and only externalize services that are independent (security, logs, media files management, … etc)
Author
