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?
VP of Product Management, 10,001+ employees
The term microservice is another misused (or misrepresented ) term in Industry. While the concept of Microservice was conceptualized in Netflix, you have to understand that Enterprises run a lot more services than any of these product companies do. If you start breaking the services into micro services, you will get more services to manage.!The monitoring, recovery of these services becomes more difficult as the number of services grow. The unbundling of monolithic services need not necessarily require you to break your service architecture into micro services, you can also apply domain driven design for services, that will help you build a more flexible architecture without having to support many micro services. CIO, Senior VP in Finance (non-banking), 1,001 - 5,000 employees
From an Enterprise perspective, the last thing I need is more services. I need more comprehensive applications, not a larger number of them.VP Systems Engineering in Software, 1,001 - 5,000 employees
Microservices modelling like neurons, searching and finding optimal paths for connection to a relative microservice and forming new applications unintended and innovative beyond designPartner in Finance (non-banking), 11 - 50 employees
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.
CTO in Software, 11 - 50 employees
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.CTO in Finance (non-banking), 11 - 50 employees
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.
Chief Technology Evangelist in Software, 501 - 1,000 employees
Microservice Architecture (MSA) is moving to the next level with the characteristics it required in production systems for enterprises. Grouping and federation of microservices is a necessity when it comes to multiple decentralized teams working together and the number of microservices getting increased. I've published a reference architecture (Cell-based) to address the practical issues Microservice Architecture (MSA) has. Cell-based architecture using Domain-driven Design (DDD) as the foundation and inheriting the Cloud-native concepts. The full spec can be read from https://git.io/fpwtf, released under CC BY 4.0 so feel free to contribute, comment, and criticize :).
Content you might like
More valuable33%
Same value39%
Less valuable28%
160 PARTICIPANTS
Director of IT in Manufacturing, 5,001 - 10,000 employees
I sorry I never found the AI tools to conduct assessment of IT Contract, I suggest to you , you can create customize internal tools to screen it contractChief Technology Officer in Software, 51 - 200 employees
A few ways our analytics team has started using AI/MLAutomated Anomaly Detection in data >>
ML models analyze system behavior and detect anomalies that could indicate potential problems. This helps in proactive ...read more
100%13%
Greater than 50%54%
50%14%
Less than 50%14%
0%3%
682 PARTICIPANTS