4 ms·

Microservices is about tradeoffs. Many people will reiterate this over the coming years and attempt to make it clear its not the be all and end all of software

by chuhnk 10y ago

Microservices is about tradeoffs. Many people will reiterate this over the coming years and attempt to make it clear its not the be all and end all of software engineering. Before it had this name it was known by many others. It is in fact simply distributed systems. The logical evolution of ones architecture when scaling from zero to orders of magnitude beyond is to eventually split out functionality so it can be worked on and scaled independently. That's it, that's all its about. And over time you find this becomes the pattern that helps stabilise and speedup an organisation as the number of people increase. Most of the time it's an organic process. I would never tell anyone to start with microservices but to merely keep these ideas in the back of their mind and pick tools that simplify the process of moving to distributed systems later.

kpil 10y ago
True. No silver bullet this time either... But right now it's a cool thing, since google is doing it. And Netflix, or whatever. Organisations are about to waste crazy amount of money on microservification of "monolithic" applications that are perfectly fine, because they think it will solve all of their problems. Microservices are not solving complexity, it is adding complexity in order to solve problems related to scalability and size, and you need to be good to pull it off. If you are working in a half-arsed inhouse development department in a medium sized company in a uninteresting business, chances are that the organisation (as a whole) is not good enough even if there are some smart people around, and you should be grateful that the RDBMS is there and rolls back problems caused by the shitty code that keeps piling up in your git repository. I started working for about 20 years ago with distributed systems in the telecom industry, where we had to scale telephony services over a lot of machines, both vertically and horizontally. We had key-value datastores, services, application logic, and interfaces as small programs running in it's own machine. And it was bloody hard to handle transactions, routing, fail-overs and generally getting the right balance between calling a service or doing it locally. We did web applications like that too actually - using cgi, a custom html template format and the crappiest script language ever imaginable and it kind of worked too. It was rather ahead of it's time, much thanks to a few smart guys that were trying to solve the rather hard problem of using cheap hardware for providing very reliable telecom services. It never was "very" reliable, but it was ok. At least on sunny days. It scaled up to a point. The networks weren't that fast, and the sheer complexity of it all was a limiting factor. We had to create tools for generating the configuration and at one point I found out that we had more than 100.000 lines of configuration in a moderately large system, which explained why it took a while to assemble these systems by hand. But as time went, the hardware was catching up and you could more or less put everything in one box. And we did. And we started to use RDBMs because we could really need the power of a flexible and transactional database manager, and it was a bliss to write a large monolithic application for user provisioning and administration and not needing to handle every shitty little detail by yourself. I am very reluctant to going back to key-value stores and really small services, unless we really need the speed. It comes with a heavy cost. (Even though you get more for free now, as more people is doing it.) The best trade off in my opinion is to build as large systems as possible while it still handles the load and it is still possible to work on efficiently with a few teams. When it's hard to keep up with what is happening and how everything works, it might be better to split the system into smaller systems and (semi) independent teams. The key is the independent team, real devops, and a hard focus on making deployments fast and with no or almost no downtime. Unfortunately, where I work now, the major limiting factor of our velocity is our dependencies to other teams and systems. If we can build something on our own we can typically do a reasonable feature in between 3 days to 3 weeks. If we are depending on development by another teams changes in other systems, it minimally takes 3 weeks. And the problem grows exponentially. If 3 systems are involved, it will take us 3 months or more, and failure is always an option. I don't see how more services will solve that rather hard organisational problem, but that is apparently what some people think will happen, effortlessly, just because technology.

by chuhnk 10y ago

kpil 10y ago

True. No silver bullet this time either... But right now it's a cool thing, since google is doing it. And Netflix, or whatever. Organisations are about to waste crazy amount of money on microservification of "monolithic" applications that are perfectly fine, because they think it will solve all of their problems. Microservices are not solving complexity, it is adding complexity in order to solve problems related to scalability and size, and you need to be good to pull it off. If you are working in a half-arsed inhouse development department in a medium sized company in a uninteresting business, chances are that the organisation (as a whole) is not good enough even if there are some smart people around, and you should be grateful that the RDBMS is there and rolls back problems caused by the shitty code that keeps piling up in your git repository. I started working for about 20 years ago with distributed systems in the telecom industry, where we had to scale telephony services over a lot of machines, both vertically and horizontally. We had key-value datastores, services, application logic, and interfaces as small programs running in it's own machine. And it was bloody hard to handle transactions, routing, fail-overs and generally getting the right balance between calling a service or doing it locally. We did web applications like that too actually - using cgi, a custom html template format and the crappiest script language ever imaginable and it kind of worked too. It was rather ahead of it's time, much thanks to a few smart guys that were trying to solve the rather hard problem of using cheap hardware for providing very reliable telecom services. It never was "very" reliable, but it was ok. At least on sunny days. It scaled up to a point. The networks weren't that fast, and the sheer complexity of it all was a limiting factor. We had to create tools for generating the configuration and at one point I found out that we had more than 100.000 lines of configuration in a moderately large system, which explained why it took a while to assemble these systems by hand. But as time went, the hardware was catching up and you could more or less put everything in one box. And we did. And we started to use RDBMs because we could really need the power of a flexible and transactional database manager, and it was a bliss to write a large monolithic application for user provisioning and administration and not needing to handle every shitty little detail by yourself. I am very reluctant to going back to key-value stores and really small services, unless we really need the speed. It comes with a heavy cost. (Even though you get more for free now, as more people is doing it.) The best trade off in my opinion is to build as large systems as possible while it still handles the load and it is still possible to work on efficiently with a few teams. When it's hard to keep up with what is happening and how everything works, it might be better to split the system into smaller systems and (semi) independent teams. The key is the independent team, real devops, and a hard focus on making deployments fast and with no or almost no downtime. Unfortunately, where I work now, the major limiting factor of our velocity is our dependencies to other teams and systems. If we can build something on our own we can typically do a reasonable feature in between 3 days to 3 weeks. If we are depending on development by another teams changes in other systems, it minimally takes 3 weeks. And the problem grows exponentially. If 3 systems are involved, it will take us 3 months or more, and failure is always an option. I don't see how more services will solve that rather hard organisational problem, but that is apparently what some people think will happen, effortlessly, just because technology.