I think this is an excellent introduction to the tech side.
I do sometimes think that "Getting started" articles should sometimes be prefaced with a "here's who this isn't for" - particularly with architectures designed for scale not simplicity. I tend to think if you're in a situation that demands microservices, you should already know the tech stuff :-) The hard bit about getting started is really reconfiguring the team.
I have to say I'm sick of the microservices fad. For the 99% it makes no sense to incur the complexity cost because YAGNI unless you seriously plan on scaling to FB/Google/etc levels...and realistically if your little app blows up to that level, you can figure out how to break it apart into 'micro' services when and where it makes sense to do so.
Modularity is central in MsA; don't like the way this service is designed or something better is available (FaaS) with lower implementation cost than net-new, in-house services.
Keep the Monolith flame burning. They will always have a place.
I think there is a useful small-scale pattern of 100% independent tiny apps - not quite microservices, since you don't really have to jive with discovery and things, but it's not obviously wrong. However, I do think in many instances, splitting stuff into separate services at this level can be a form of premature optimization, and it can easily create a lot of drag when a monolith is much easier to refactor and munge.
>realistically if your little app blows up to that level, you can figure out how to break it apart into 'micro' services
I disagree, when your little app blows up and your backend dies, then you could very well miss your big break. In this crazy world of overnight success you need to be ready to handle the HN or Reddit hug-of-death.
Maybe you don't need to split your infrastructure into services, but doing so makes scaling a breeze.
You can scale monoliths. Twitter did it until it could retool (remember the more-or-less daily fail whale?) Disqus & Pinterest scaled django to more users than most of us will ever have.
Twitter is the perfect counter example of how to build for scaleability. Not only becUse of the fail whale you mentioned, but Twitter is still a bloated mess of an organization.
While microservices might be helpful for scaling from a perf level, a lot of the situations where I've seen microservices apply is the organizational scale challenge.
How do you get lots of engineers to work on a single monolithic application, while releasing the app into production on a very frequent basis (e.g., daily)?
The traditional answer has been to add complexity into your workflow (e.g., feature freezes, staging environments, code reviews, more testing). These are all reasonable things and good ideas. But at some point your velocity starts to slow down dramatically because of all this complexity.
Worst of all, this complexity isn't necessary for every feature. You might be prototyping some stuff, for example. But a monolithic architecture forces everyone onto the same workflow.
Microservices enables different workflows for different features (services). The value of this, even when you're at a small scale, can be pretty significant.
This is similar to why we are doing it ... our app is quite simple, with about 5 moving parts. But we need it to be able to keep running continuously while allowing each part to be upgraded independently, and to be able to shut off the valve of messages going to each part so we can upgrade it and test it without bringing other parts down. Several of the parts share data models and underlying code ... so perhaps they are not true "microservices" ... but to the extent they are, for us there are some useful aspects to the fad.
First, tutorials like this should include getting this running using TLS by default. Ideally there shouldn't be any reference to plain http at all.
Second, the DSL for Kube and Ambassador seem ridiculously complex for this. Maybe some explanation for what "imagePullPolicy: IfNotPresent" means? This kind of configuration harkens back to the myriad of Jboss XML files, just in a different format. For me personally, I get all the reasons why you'd want to use k8s, but for a "getting started" user, seeing this kind of required config -- rather than sensible defaults hidden away -- would get very discouraging. ("Why should I learn this DSL instead of just making sure I had a correct puppet setup?")
So tell me why I should prefer this over Consul for service discovery, health checking, etc. and Nomad for running jobs? With Nomad, I can choose raw executables, shell scriots, jar files, docker containers, etc. I can choose batch jobs or long running services and the executables for each are less than 60Mb and they can serve as servers and clients.
16 comments
[ 5.1 ms ] story [ 51.6 ms ] threadI do sometimes think that "Getting started" articles should sometimes be prefaced with a "here's who this isn't for" - particularly with architectures designed for scale not simplicity. I tend to think if you're in a situation that demands microservices, you should already know the tech stuff :-) The hard bit about getting started is really reconfiguring the team.
Modularity is central in MsA; don't like the way this service is designed or something better is available (FaaS) with lower implementation cost than net-new, in-house services.
Keep the Monolith flame burning. They will always have a place.
I disagree, when your little app blows up and your backend dies, then you could very well miss your big break. In this crazy world of overnight success you need to be ready to handle the HN or Reddit hug-of-death.
Maybe you don't need to split your infrastructure into services, but doing so makes scaling a breeze.
https://blog.disqus.com/scaling-django-to-8-billion-page-vie...
How do you get lots of engineers to work on a single monolithic application, while releasing the app into production on a very frequent basis (e.g., daily)?
The traditional answer has been to add complexity into your workflow (e.g., feature freezes, staging environments, code reviews, more testing). These are all reasonable things and good ideas. But at some point your velocity starts to slow down dramatically because of all this complexity.
Worst of all, this complexity isn't necessary for every feature. You might be prototyping some stuff, for example. But a monolithic architecture forces everyone onto the same workflow.
Microservices enables different workflows for different features (services). The value of this, even when you're at a small scale, can be pretty significant.
First, tutorials like this should include getting this running using TLS by default. Ideally there shouldn't be any reference to plain http at all.
Second, the DSL for Kube and Ambassador seem ridiculously complex for this. Maybe some explanation for what "imagePullPolicy: IfNotPresent" means? This kind of configuration harkens back to the myriad of Jboss XML files, just in a different format. For me personally, I get all the reasons why you'd want to use k8s, but for a "getting started" user, seeing this kind of required config -- rather than sensible defaults hidden away -- would get very discouraging. ("Why should I learn this DSL instead of just making sure I had a correct puppet setup?")