This article was originally posted on Aug 21st 2018 at: https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with
...
For further actions, you may consider blocking this person and/or reporting abuse
Really great post!
As far as I know, GitHub is basically monolithic Rails too. I may be wrong though.
All architectures are simply a point in time. Starting with the ultimate solution is almost always a bad choice.
There's absolutely nothing wrong with a monolith for a good majority of applications. If everyone is working on the same core product, there's really not much to be gained by breaking it into microservices, as seen with Github. Microservices are great for exactly that, services, and if your application needs to integrate with tons of other products and your team is the one maintaining those integrations, that's when you need microservices. As an ecosystem, Github really kind-of is built on microservices, they just call them 3rd-party applications. The core of Github is called a monolith just because they aren't the ones maintaining all the other services.
Let's face it... most current mature frameworks and programming langauges just dont adapt with microservices.
I'm talking about Rails and Django :(
Thanks. dev.to is also a monolith too right?
It seems to scale just fine with a quick loop on rolling out new features.
Yeah, traffic scaling is not a problem. Team-scaling remains to be seen, but I'm pretty happy with our outlook there.
How do you handle traffic scaling for monolith application? Just copy the application in different machine and allow load balancer to distribute traffic?
A couple of ways.
Vertically scale (add more computing power to a server) and then tinker with your app server's scaling properties. For example with Puma (a popular Rails app server) you can increase its workers and threads which in turn use more system resources.
Horizontally scale (add more servers) and then load balance them like you mentioned.
You could also do a combination of both.
For horizontal, there may be serveral technical issue I think.
For most application, the bottleneck would be in database. I mean the performance.
For the transactional issue, it could be done through pessimistic lock and optimistic lock I think.
For microservice, I often have a question for session. How can I get session info across different microservice component.
You can use a load balancer that supports sticky sessions, this way users are always routed to the same server.
Your cache would typically live outside of your application instance. For example with Rails you could use Redis as your cache backend and Redis would be running on its own server that's unrelated to your load balancer.
That's typically what people mean when they say they run "stateless" servers. For horizontally scaling most web applications, you want to keep them as dumb as possible. They should be disposable. I would strive for that even if you plan to do a small single server deployment.
I've dealt with some pretty big web apps before. A single SQL database can go a really really really really long ways as long as you avoid silly mistakes like N+1 queries and understand how to profile slow queries on demand. You can also cache expensive queries to avoid hitting your DB entirely.
I have to disagree. While as the article stated microservices are suited for a very large scale and specific scenario, in my experience containers solve problems common to even the smallest personal website deploy. They basically standardized a packaging format and configuration best practices, while before you probably had your zip, jar o executable that you had to copy to a server, unpackage/drop into an application server/run, changing obscure files to configure it for production use, now from an operation standpoint it doesn't matter how your application is put together. We have centralized repositories (container registries), a single method of distribution (
docker pull/push), a single way of starting an application or a service (docker run) and a single way or changing configurations (via environment variables). I migrated old Rails apps from a manual deploy to a containerized solution and even if they are simple monoliths used by maybe 50 people it made iteration and deploy so much easier and faster I would never go back.Kubernetes is another topic altogether, it is only useful when you have more than 30/50 containers to handle. But it can really help you scale out, even if the application is a simple monolith (monoliths still have to scale to accommodate traffic, spinning up more instances behind load balancers predates or microservices) being able to handle container lifecycle and scaling from a single point, having centralized monitoring and logging and easily scale to multiple machine if needed can really bring value to a business.
Thanks for the article Nick, big respect for your level of experience and insight applied here!
I like to do rapid prototypes and I've written a number of "tiny" monolithic applications, so what I'm about to write is a gut reaction based off where I am in my journey (devving for 15 years, pro for just 6):
The first version of a product (call it an MVP, whatever) is probably small enough that it can - by some stretch - be thought of as a microservice. Future developments to the product make sense either as extensions to what that service does or as new services.
My point is that if you sit down and start writing cloud-first code in today's PaaS climate, you'll write something that is not far from a microservice itself.
In fact, recently our team was writing an offline server-to-hardware integration (totally not cloudy at all) and we ended up building a number of services around an events queue as if by accident. No cloud! Perhaps there is a natural pull towards SOA as a sensible infrastructure in a wider variety of cases than we expect? (Link for the curious)
Love your post! I totally agree with it, I'm a big fan of the YAGNI (You Aren't Going To Need It) principles, which evolved into guidelines for me that are ver similar to the ones you describe. Software should always be an evolution, don't try and solve problems you don't have yet.
The list of "Levels of Abstraction" is so incredibly accurate, I love it! You really have no reason to create an external library if you haven't taken the time to really understand the problem, explore other avenues, figure out all the possible use-cases, and have a plan for how to abstract and build the library.
Totally agree on that, the monolithic is the way to go till you get clearer service boundaries and... move to the cloud services to infinitely scale (and get locked-in) :D