Thinking about the architecture of applications, we've seen for a while now that monolithic applications have been unbundling into microservices. What is the future of microservice architecture?
Sort by:
Having said that, the way to think about product and software architecture is around resiliency and fault isolation, which a microservices architecture helps with. Everything will fail at some point, and having circuit breakers in place to prevent cascading failure is paramount. If you don't architect in this manner, you often end up with a 'microlith', meaning that you have distinct API endpoints but the layers behind have multiple dependencies and the entire application tips over when any single component fails.
Well, I'm cautious about expressing a strong view on this, because application architecture is a notoriously controversial topic. One of the guaranteed ways to start a flame war on Hacker News is to take a strong position about monoliths versus microservices.
Having said that, let me tell you my perspective, not from the enterprise IT world, which I don't know as well, but from the early stage startup world, which is what we see here at Y Combinator.
When you're starting a new company, the most important goal to solve, with your infrastructure, is actually not its long term sustainability, scalability, uptime, and completeness. In the earliest stages, the most important thing is actually speed of iteration, that is actually the thing that you want to optimize for. And, one of the things that I think is dangerous is when small companies tend to want to copy large companies in everything. Not just in software, in how they do sales, how they do marketing, hiring, everything.
As a consumer, you have much more experience with large companies than you have with small companies. You want your company some day to be a large company and so it's very natural to copy the patterns that you see with large companies, with your new startup. That can be really dangerous, because sometimes the choices that a large company like Uber makes that make tons of sense for them and are really great choices, are terrible choices for your early stage startup.
I think microservices is probably an example of this, where if you've worked as a software engineer at a large company, you've probably seen this problem that in the early days, the early engineers built this monolithic application and over time it got super unwieldy and required lengthy testing cycles and it was really easy to break and was really hard for new people to learn their way around this code base. Then they began this process of breaking up the monolith into a bunch of microservices so they can iterate quickly, and it was a really painful process. Maybe you're one of the engineers who worked on this process of breaking up the monolith, and it really sucked.
So, you leave the large company and you start your own company, and you're like, "Well, when I do my company, that's one mistake I'm not going to make. I'm not going to start with a monolith because I know how painful it's going to be when we get too big. So, I'm going to start with the newest, fanciest, microservice architecture, and oh, also I'm going to have a hundred percent test coverage from day one, I'm going to have a hundred percent uptime and I'm going to have extremely well commented code and integration tests and I'm going to have all these things that I wished we had had in my last company."
The problem is, if you spend all of your time doing those things then you may fail to do the most important thing that all companies have to do, which is to ship a product that people want. So, that's my take on microservices architecture for early stage startups: use with caution.
Microservices modelling like neurons, searching and finding optimal paths for connection to a relative microservice and forming new applications unintended and innovative beyond design
From an Enterprise perspective, the last thing I need is more services. I need more comprehensive applications, not a larger number of them.
I have always looked to biology as inspiration in architecting systems. Organisms are only as complex as required and even more complex organisms, like humans, are somewhat ecosystems as we have several symbiotic relationships such as with bacteria.
Micro services is a great buzzword but hard to manage as a true micro service is self contained. Generally, there are common libraries that get reused for code efficiency as well as the need to access common data structures and storage.
I do think the service oriented approach will continue to move forward. The key is to group services into components that can run and scale independently and bound together by well defined interfaces (eg APIs). They key is to ensure that one component, such as a web all, is dependent on the interface and not the internal workings of another component, such as a service layer.