4 ms·

> You can rent a fleet of computers for an hour for a few dollars. On which you deploy an web app that has 30 working components written in 10 different langua

> You can rent a fleet of computers for an hour for a few dollars. On which you deploy an web app that has 30 working components written in 10 different languages that is able to do a fraction of the work a single vertically scaled server that runs 3 C written components. And has less than two 9 uptime. No one person can grasp it mentally. Is statically linked and must be updated piece by piece, unable to use the distribution repos and upstream work. Oh, and man, what man? Every one of the 30 components is "open core" with cool new invented terminology that pushes you into paying for consulting or reading spaghetti "object oriented" code. It also has stack trace for logging. How ungrateful of little sysadmin old me not to appreciate progress.

sascha_sl 7y ago
Your comment mirrors the article. A bunch of projection, written out. Lots of people do microservices for the wrong reason, with the wrong model. They don't realize this model asks for a lot of initial overhead per process for visibility and early investment into figuring out how these services communicate. For instance, a service that sets off 3-4 layers of HTTP requests is an indicator of a bad microservice architecture. A service that uses a shared data bus (e.g. Kafka) but can survive without it however... That doesn't mean things are regressing. People have always done the wrong things for the wrong reasons.
- trabant00 7y ago
  It is a distinct possibility that I am unable to find work for the x% for organizations that use the microservice model correctly.
  - marcosdumay 7y ago
    It's very likely that anybody that you know that uses microservices even before working there is using them wrongly.
- foobarqwertz 7y ago
  Can you give some directions(links) on good microservice architectures and the right reasons to deploy those?
sgt101 7y ago
So, why are we doing this? In truth because the world of C (I was a C and then C++ programmer 30 years ago) did not enable the production of effective applications cheaply and quickly. Yes - you can write anything, but it took months and months and months. We've traded efficiency for productivity. We have been able to do this because of Moore's law and all its friends. Also, C code is hellish to read and understand (#define anyone?), and logging almost never happened. As a sysadmin you will be able to look at the organisation you work in and count up the number of sysadmins, my guess is that there are less than 50% of the number 10 years ago, maybe that's the problem?
- jcelerier 7y ago
  > Yes - you can write anything, but it took months and months and months. The C & C++ of 30 years ago, where compile times took days - sure. Nowadays building a whole yocto software stack, basically a full linux distro - from GCC, to the kernel, to glibc, to X11, to Qt takes 6 to 8 hours in a good laptop. In addition, modern language features & the general shift from runtime to compile-time polymorphism, especially in C++, make the potential for errors decrease sharply, and language simplifications - standard library improvements, terser syntax, also make time to release go down. Finally, tooling has greatly improved : I barely ever need to run a build with my IDE to check for errors, because IDEs now embed clang, clang-tidy, clazy... which checks your code as soon as you type and highlight it in the editor. And asan, ubsan, handle the remaining cases which cannot be caught at compile time, leaving only logic errors to handle.
  - AstralStorm 7y ago
    This. The one problem is a lack of a solid networking library. Unix sockets/winsock is ancient and terrible with tons of corner cases, Boost ASIO is creaky and "boosted", other useful things like 0mq are good for IPC but not Internet. Qt eats the world and is a pain to integrate. Libevent, libev etc. are not C++ and still pain to integrate. Maybe there is some library that is lesser known but good. As for time to develop, besides networking, C++ wins, even for hack projects, in comparison with Python even, JS/HTML/CSS w/ framework stack being far slower and making for terrible UX. (I'm not writing about languages I do not use.) Java and C# can be fast too, but it hits the limits when you actually have to calculate things which gets real awkward real fast. The main win is... Tooling. Java tooling is best now since maven and ant are mostly gone legacy, then C++ (I'm counting Qt Creator and Glade, cmake is eh, cmake+something is ok), then finally JS tied with Python. JS fails terribly on debugging and the creaky rarely adaptable UX libs, while Python after all these years still has tooling issues. (Plus performance where it matters.) Rust is not there yet, maybe soon. Scala is nice though fewer people can use it than new C++. Honorable mention to specialized tools like R, Faust, Lua, Matlab and Fortran. Note they integrate well with C and C++... Try anything else and you're in for a ride. Even second most supported, C# and Java, go through a C FFI layer.
taneq 7y ago
That's because as a sysadmin you can now do work in a week of plugging components together that would have taken three months for a team of five to pull off with C.
- trabant00 7y ago
  Problem is no amount of plugging and configuration on my part can fix problems that come from the complexity of the software architecture. I can imagine it's a lot cheaper. But what is the compared value/quality? I reckon it's below the slow and steady approach. You are free to argument against.
theamk 7y ago
Don't work in such place then? Seriously, there are always good and bad places. In fact, when you said "two nines" -- this is like 15 minutes of downtime per day -- I immediately thought about one of my jobs (long time ago) which involved website running on Windows Server, using a mix of ASP and DLL files. It would routinely go down for tens of minutes each deployment because someone would update the DLLs in the wrong order. There was also using PHP with Apache. As a sysadmin, remember all those times when you had to hunt all the Apache-spawned processes and kill them by hand, so you can finally apply new configuration? Or when an .so file update made an app server not start, but that darned start-stop-daemon was silently eating both exit code and error message? It got much better in the sysadmin world -- it is now easy to do the sane things, and all that containerization means that if programmers do provide something insane, it is trivial to clean up the mess.

sascha_sl 7y ago

Your comment mirrors the article. A bunch of projection, written out. Lots of people do microservices for the wrong reason, with the wrong model. They don't realize this model asks for a lot of initial overhead per process for visibility and early investment into figuring out how these services communicate. For instance, a service that sets off 3-4 layers of HTTP requests is an indicator of a bad microservice architecture. A service that uses a shared data bus (e.g. Kafka) but can survive without it however... That doesn't mean things are regressing. People have always done the wrong things for the wrong reasons.

trabant00 7y ago
It is a distinct possibility that I am unable to find work for the x% for organizations that use the microservice model correctly.
- marcosdumay 7y ago
  It's very likely that anybody that you know that uses microservices even before working there is using them wrongly.
foobarqwertz 7y ago
Can you give some directions(links) on good microservice architectures and the right reasons to deploy those?

sgt101 7y ago

So, why are we doing this? In truth because the world of C (I was a C and then C++ programmer 30 years ago) did not enable the production of effective applications cheaply and quickly. Yes - you can write anything, but it took months and months and months. We've traded efficiency for productivity. We have been able to do this because of Moore's law and all its friends. Also, C code is hellish to read and understand (#define anyone?), and logging almost never happened. As a sysadmin you will be able to look at the organisation you work in and count up the number of sysadmins, my guess is that there are less than 50% of the number 10 years ago, maybe that's the problem?

jcelerier 7y ago
> Yes - you can write anything, but it took months and months and months. The C & C++ of 30 years ago, where compile times took days - sure. Nowadays building a whole yocto software stack, basically a full linux distro - from GCC, to the kernel, to glibc, to X11, to Qt takes 6 to 8 hours in a good laptop. In addition, modern language features & the general shift from runtime to compile-time polymorphism, especially in C++, make the potential for errors decrease sharply, and language simplifications - standard library improvements, terser syntax, also make time to release go down. Finally, tooling has greatly improved : I barely ever need to run a build with my IDE to check for errors, because IDEs now embed clang, clang-tidy, clazy... which checks your code as soon as you type and highlight it in the editor. And asan, ubsan, handle the remaining cases which cannot be caught at compile time, leaving only logic errors to handle.
- AstralStorm 7y ago
  This. The one problem is a lack of a solid networking library. Unix sockets/winsock is ancient and terrible with tons of corner cases, Boost ASIO is creaky and "boosted", other useful things like 0mq are good for IPC but not Internet. Qt eats the world and is a pain to integrate. Libevent, libev etc. are not C++ and still pain to integrate. Maybe there is some library that is lesser known but good. As for time to develop, besides networking, C++ wins, even for hack projects, in comparison with Python even, JS/HTML/CSS w/ framework stack being far slower and making for terrible UX. (I'm not writing about languages I do not use.) Java and C# can be fast too, but it hits the limits when you actually have to calculate things which gets real awkward real fast. The main win is... Tooling. Java tooling is best now since maven and ant are mostly gone legacy, then C++ (I'm counting Qt Creator and Glade, cmake is eh, cmake+something is ok), then finally JS tied with Python. JS fails terribly on debugging and the creaky rarely adaptable UX libs, while Python after all these years still has tooling issues. (Plus performance where it matters.) Rust is not there yet, maybe soon. Scala is nice though fewer people can use it than new C++. Honorable mention to specialized tools like R, Faust, Lua, Matlab and Fortran. Note they integrate well with C and C++... Try anything else and you're in for a ride. Even second most supported, C# and Java, go through a C FFI layer.

taneq 7y ago

That's because as a sysadmin you can now do work in a week of plugging components together that would have taken three months for a team of five to pull off with C.

trabant00 7y ago
Problem is no amount of plugging and configuration on my part can fix problems that come from the complexity of the software architecture. I can imagine it's a lot cheaper. But what is the compared value/quality? I reckon it's below the slow and steady approach. You are free to argument against.

theamk 7y ago

Don't work in such place then? Seriously, there are always good and bad places. In fact, when you said "two nines" -- this is like 15 minutes of downtime per day -- I immediately thought about one of my jobs (long time ago) which involved website running on Windows Server, using a mix of ASP and DLL files. It would routinely go down for tens of minutes each deployment because someone would update the DLLs in the wrong order. There was also using PHP with Apache. As a sysadmin, remember all those times when you had to hunt all the Apache-spawned processes and kill them by hand, so you can finally apply new configuration? Or when an .so file update made an app server not start, but that darned start-stop-daemon was silently eating both exit code and error message? It got much better in the sysadmin world -- it is now easy to do the sane things, and all that containerization means that if programmers do provide something insane, it is trivial to clean up the mess.