8 ms·

When are containers or serverless a red flag?

35 points by ohjeez 3y ago

speedgoose 3y ago
I can’t talk much about serverless, I briefly tried some frameworks during the hype and I haven’t been convinced. It did sound more annoying and expensive than copying files using ftp to cgi-bin or mod_php managed servers like in the 90s and 2000s. About software containers I think that the complexity is very very much worth it. Being able to ship software that run on my machine and will run about the same in production is so convenient. Running applications with conflicting dependencies is not a problem. Installing up to date or legacy software without breaking the operating system is also trivial. Sure kubernetes is complex but it’s a bit more than running containers. A good start is using Docker or podman directly. You can see the value of kubernetes or nomad later.
- samtho 3y ago
  The concept of “serverless” is just based around trying to recreate a cgi from a long-running process application. Like you pointed out, we have had this since mod_php.
  - MrBuddyCasino 3y ago
    Except we didn’t have spend a day to get the IAM permissions just right and embed some javascript into a huge blob of YAML. Simpler times.
    - biorach 3y ago
      Also, less secure times
      - samtho 3y ago
        Maybe in general, but that does not encompass every project or organization utilizing web technologies. There was technical know-how but often just a lack of willingness or understanding from higher up that prevented a security-focused approach to building applications.
  - fauigerzigerk 3y ago
    Serverless is CGI for dynamically allocated server clusters managed by other people. We didn't have that.
    - samtho 3y ago
      From the user’s point of view (someone developing an application), we did via shared hosting and cgi-style scripting. It doesn’t really matter what tech powered the infrastructure as long as it worked. Putting PHP scripts on in a folder to be called at will to perform specific actions was a pattern utilized to great effect with the additional benefit of not having to wait for the function to spin up.
  - nailer 3y ago
    Wasn’t the creation of mod_ the ability to keep the interpreter open? Yes, before that, we had stateless scripting in web apps. Like serverless it was far easier to debug. Unlike serverless it was slow.
- ghnws 3y ago
  In my experience, you gain enough knowledge to set up a new container service in minutes fairly fast. I opt for containers because to me it's the perfect balance of ease of use, maintainability and performance. Managing container orchestration is completely optional too. All cloud platforms offer it as a service. With serverless I've had more trouble than benefits. It's not easier than containers to set up - often quite the opposite. When (not if) you encounter performance issues, they are either difficult to solve or simply impossible. I have never had this experience with containers.
samtho 3y ago
The quality of this article feels kind of dubious. There are ideas here that have some merit but some of the background smells like it was generated. That aside, I’m a little put off by the grouping of containers and serverless as if they exist at the same level which could warrant a coherent discussion. For example, given that serverless is simply a way to spin up on-demand, ad-hoc http endpoints, the vendor lock-in argument is going to be stronger than the same argument about an OCI spec container. Maybe I’m in a bubble, but there isn’t much substance here that isn’t already known: using serverless as a crutch is a terrible idea if you are looking to actually scale and containers, well, exist.
- alephnerd 3y ago
  It's a submarine article for Deloitte Consulting's Cloud Practice. The writer of the article is affilated them and I myself have had Content Marketing teams ghostwrite articles with my name on InfoWorld for "Demand Gen". You will see tons of "thought leadership" articles this month as June is when infrastructure, networking, and cybersecurity products are released as these releases are timed with industry conferences.
laeri 3y ago
What does the author mean with containers? This articke seems little content. A container is basically never a bad idea. Serverless will drive how your application behaves and how it is written and seriously affect anything else. However, containers is just a matter of deployment and what substrate is used. I can deploy an application into a container on my vps or any of those hosted solutions out there. The article groups these together unnecessarily. I agree with the matter of vendor lockin though.
- bandrami 3y ago
  > A container is basically never a bad idea Eh. If I'm running nginx on Debian I have to worry about Debian and Debian's version of nginx. If I'm running an nginx container on Debian I have to worry about Debian, Debian's container manager, the runtime nginx is containerized with, and the version of nginx in the container. The release cadence of Debian is well-known and can be planned around. The release cadence of an nginx container is not well-known, and is another thing the intern can configure wrong (I still shudder every time I see shops use "FROM foo:latest" in production, which is shockingly common). Not to mention the addition of an entire new class of supply chain vulnerabilities to worry about/mitigate (yes, I can build my own container, but I can also just build my own .deb file).
  - jupp0r 3y ago
    You can use Debian stable as a base image and run its nginx everywhere where there is Linux. The host OS doesn't matter much if everything is containerized.
    - bandrami 3y ago
      Except the host does matter, that's the thing, because you're still ultimately running on it. I remember this really bit me once in the RHEL 6 to 7 shift when the syscall semantics changed. Our brilliant plan of keeping our applications in RHEL 6 containers and running them on 7 while we did the upgrade, but everything realtime failed (these were audio processing engines) because of that ABI change. Not to mention the fact that your stack is only as secure as its least secure element, and now you've got two (or more) platforms to keep an eye on for that.
jupp0r 3y ago
> Container and serverless platforms introduce additional complexity that the teams building and operating these cloud-based systems must deal with. This is bizarre. Cloud functions are really the easiest way to deploy code to the internet. Compare that with the other extreme of building a house to host physical servers, hiring staff to maintain them, picking hardware and operating systems, creating procurement and maintenance procedures to keep both up to date. You have to deal with considerable amounts of HVAC design, hiring contractors, etc. On the other side, people can just write a few lines of Terraform, swipe a company credit card and deploy to millions of users. Not all technology is complicated.
- SahAssar 3y ago
  You're conflating complex and hard. Cloud functions might be easy, but they are also complex, and there are definitely specifics you need to keep in mind when developing them.
  - jupp0r 3y ago
    There's a lot of complexity in the stack that makes a web server run. Nobody would suggest designing their own chips to do so. People insist that cloud computing is adding complexity when it often is a useful abstraction that allows companies to concentrate on the stuff that provides business value vs having to deal with lower levels of the stack.
  - nailer 3y ago
    The sibling post already makes the same point, but I absolutely agree that serverless is specifically less complex than maintaining state for monolithic applications. Individually deploying endpoints in seconds is hugely beneficial. Likewise functional purity is easier to reason about.
- tiew9Vii 3y ago
  I find the actual deployment with cloudfunctions easy as you say. The complexity is the orchestration, the architecture, the hard vendor limitations, having to deal with being a distributed system. Having a FAAS service makes the deployment easy but development wise a traditional monolith deployed on static servers can be far simpler to deal with. I use FAAS (Lambda's /cloudflare functions) a lot for pet projects as it costs me fractions of a cent to host. The architecture is quite complex being distributed, dealing with restrictions, eventual concurrency etc etc. I find it enjoyable making things work in these systems basically for free but if these projects where a business with paying customers, alot of the stuff I'd drop from FAAS and deploy on static VPS servers as architecture is so much easier meaning I'm much more productive. With paying customers I can take the additional cost of a few VPS's or dedicated hosts such as Hetzner. The FAAS wouldn't outweigh the productivity gains.
matthewmacleod 3y ago
Not a great article but the underlying point has merit. My personal framework: - Always use containers, unless you can’t - Never use serverless, unless you must And above all, regardless of what you choose, keep the complexity to a minimum. Script and automate everything, eliminate manual processes, and never use two services when one will do. YMMV.
politelemon 3y ago
Discussing tech choices early on is always going to happen. You can try and be a purist and tell everyone to just talk requirements, but people are people, and requirements and tech are intertwined. An unreasonable requirement may suddenly make complexity balloon, but if early on it's spoken out loud that requirement XYZ is very difficult with technology ABC, it may emerge that the requirement was only a nice to have and can be lived without. So it goes both ways. There are still mitigations around this, just my opinion. So running in containers means you have a reasonable level of confidence that it can run in many places. How you run it in containers may make a difference. Standalone on its own represents a very small investment of overhead, but it's on a VM, still not terrible. k8s is a popular way to do it but is massive, and is not that different from a lock-in. Fargate and Container Apps take away a lot of that overhead and the lock-in is minimal, because you can escape to other kinds of hosting quite easily. I'd pick Fargate over the other choices where possible.
- kristopolous 3y ago
  I tackle this problem by focusing on building the product, not the infrastructure and making sure the first version works just for me. Once you hitch your wagon to anything you're along for their ride and have to make sure you can still do your own thing while wrangling your dependencies. So choose things that don't move very fast and don't ask much time from you
erik_seaberg 3y ago
Containers, like static linking, protect you from someone else’s platform if you can’t rely on it. But if it’s your own platform, why can’t you rely on it? Who’s maintaining it?
- drpixie 3y ago
  Best summary of containers - clear and hits the point.
- pkulak 3y ago
  Maybe you just want the ability to run on any platform.
- nailer 3y ago
  > But if it’s your own platform, why can’t you rely on it? Who’s maintaining it? I don’t know if this is a rhetorical question. You are now responsible for maintaining your custom environment. Obvious reasons why you can’t rely on maintaining your own platform include a lack of time for maintenance, a lack of understanding of the platform you have built, and a lack of prioritisation compared to other requirements. A huge amount of the value that senior admins provide is simply stopping junior and mids from building custom platforms usually because they’re excited about a technology rather than aware of the wider picture.
  - WJW 3y ago
    > a lack of understanding of the platform you have built There is also the common extension to this problem: someone else built this platform some time ago and has long since left the company.
    - nailer 3y ago
      Yes exactly! Or “this has a bug, is only understood by one person and he’s busy right now”.
  - erik_seaberg 3y ago
    Yeah, when I say “our own platform,” I’m thinking something like “we run Debian bullseye 11.7 in prod, build a .deb for that.” Starting our own unique distro in a Docker container is not a good use of time.
getoffmyyawn 3y ago
For me, a technology itself isn't a red flag. Not being able to explain the reason for choosing one approach over another is a big red flag. Or if the reason is "I want to try this new thing" and not "Our standard production stack won't work for this because (valid technical reasons)" that's a huge red flag.
- rbanffy 3y ago
  Some combinations tend to be red flags. Most Windows server setups are, for instance. I find it alarming to see PHP or Django applications deployed on IIS. There are some situations where Windows may be the best answer - compliance and fleet management, for instance - but unless you are running a Microsoft app that requires (or works better with) Windows, it is a lot of extra attack surface. I would be immediately suspicious of an IBM mainframe or an IBMi lying directly exposed on the internet as well. I know web servers run under IBMi and zOS, it’s just that it seems like a crazy choice - that’s not what those machines are designed for. As for that being a red flag rather than a suspicious choice, my attitude is always to find a reason for it - just assuming idiocy is both unkind and arrogant - there may be valid reasons for the craziest choices. As an aside, in the late 90’s a Brazilian ISP and portal went proudly with Novell’s Netware. They died without a trace after numerous outages and nobody was really surprised. If you are doing something nobody else is doing, you are either crazy or very clever and the odds are almost never favouring clever.
nailer 3y ago
If the company isn’t a cloud provider and they have their own k8s installation.
1attice 3y ago
This article feels like it was written by a disaffected '00s developer who misses Capistrano. The point of this article is to associate containers (a foundational technology) with "severless", which peaked as a search term back before the 19 in COVID19.

35 points by ohjeez 3y ago

I can’t talk much about serverless, I briefly tried some frameworks during the hype and I haven’t been convinced. It did sound more annoying and expensive than copying files using ftp to cgi-bin or mod_php managed servers like in the 90s and 2000s. About software containers I think that the complexity is very very much worth it. Being able to ship software that run on my machine and will run about the same in production is so convenient. Running applications with conflicting dependencies is not a problem. Installing up to date or legacy software without breaking the operating system is also trivial. Sure kubernetes is complex but it’s a bit more than running containers. A good start is using Docker or podman directly. You can see the value of kubernetes or nomad later.

samtho 3y ago
The concept of “serverless” is just based around trying to recreate a cgi from a long-running process application. Like you pointed out, we have had this since mod_php.
- MrBuddyCasino 3y ago
  Except we didn’t have spend a day to get the IAM permissions just right and embed some javascript into a huge blob of YAML. Simpler times.
  - biorach 3y ago
    Also, less secure times
    - samtho 3y ago
      Maybe in general, but that does not encompass every project or organization utilizing web technologies. There was technical know-how but often just a lack of willingness or understanding from higher up that prevented a security-focused approach to building applications.
- fauigerzigerk 3y ago
  Serverless is CGI for dynamically allocated server clusters managed by other people. We didn't have that.
  - samtho 3y ago
    From the user’s point of view (someone developing an application), we did via shared hosting and cgi-style scripting. It doesn’t really matter what tech powered the infrastructure as long as it worked. Putting PHP scripts on in a folder to be called at will to perform specific actions was a pattern utilized to great effect with the additional benefit of not having to wait for the function to spin up.
- nailer 3y ago
  Wasn’t the creation of mod_ the ability to keep the interpreter open? Yes, before that, we had stateless scripting in web apps. Like serverless it was far easier to debug. Unlike serverless it was slow.
ghnws 3y ago
In my experience, you gain enough knowledge to set up a new container service in minutes fairly fast. I opt for containers because to me it's the perfect balance of ease of use, maintainability and performance. Managing container orchestration is completely optional too. All cloud platforms offer it as a service. With serverless I've had more trouble than benefits. It's not easier than containers to set up - often quite the opposite. When (not if) you encounter performance issues, they are either difficult to solve or simply impossible. I have never had this experience with containers.

samtho 3y ago

The quality of this article feels kind of dubious. There are ideas here that have some merit but some of the background smells like it was generated. That aside, I’m a little put off by the grouping of containers and serverless as if they exist at the same level which could warrant a coherent discussion. For example, given that serverless is simply a way to spin up on-demand, ad-hoc http endpoints, the vendor lock-in argument is going to be stronger than the same argument about an OCI spec container. Maybe I’m in a bubble, but there isn’t much substance here that isn’t already known: using serverless as a crutch is a terrible idea if you are looking to actually scale and containers, well, exist.

alephnerd 3y ago
It's a submarine article for Deloitte Consulting's Cloud Practice. The writer of the article is affilated them and I myself have had Content Marketing teams ghostwrite articles with my name on InfoWorld for "Demand Gen". You will see tons of "thought leadership" articles this month as June is when infrastructure, networking, and cybersecurity products are released as these releases are timed with industry conferences.

laeri 3y ago

What does the author mean with containers? This articke seems little content. A container is basically never a bad idea. Serverless will drive how your application behaves and how it is written and seriously affect anything else. However, containers is just a matter of deployment and what substrate is used. I can deploy an application into a container on my vps or any of those hosted solutions out there. The article groups these together unnecessarily. I agree with the matter of vendor lockin though.

bandrami 3y ago
> A container is basically never a bad idea Eh. If I'm running nginx on Debian I have to worry about Debian and Debian's version of nginx. If I'm running an nginx container on Debian I have to worry about Debian, Debian's container manager, the runtime nginx is containerized with, and the version of nginx in the container. The release cadence of Debian is well-known and can be planned around. The release cadence of an nginx container is not well-known, and is another thing the intern can configure wrong (I still shudder every time I see shops use "FROM foo:latest" in production, which is shockingly common). Not to mention the addition of an entire new class of supply chain vulnerabilities to worry about/mitigate (yes, I can build my own container, but I can also just build my own .deb file).
- jupp0r 3y ago
  You can use Debian stable as a base image and run its nginx everywhere where there is Linux. The host OS doesn't matter much if everything is containerized.
  - bandrami 3y ago
    Except the host does matter, that's the thing, because you're still ultimately running on it. I remember this really bit me once in the RHEL 6 to 7 shift when the syscall semantics changed. Our brilliant plan of keeping our applications in RHEL 6 containers and running them on 7 while we did the upgrade, but everything realtime failed (these were audio processing engines) because of that ABI change. Not to mention the fact that your stack is only as secure as its least secure element, and now you've got two (or more) platforms to keep an eye on for that.

jupp0r 3y ago

> Container and serverless platforms introduce additional complexity that the teams building and operating these cloud-based systems must deal with. This is bizarre. Cloud functions are really the easiest way to deploy code to the internet. Compare that with the other extreme of building a house to host physical servers, hiring staff to maintain them, picking hardware and operating systems, creating procurement and maintenance procedures to keep both up to date. You have to deal with considerable amounts of HVAC design, hiring contractors, etc. On the other side, people can just write a few lines of Terraform, swipe a company credit card and deploy to millions of users. Not all technology is complicated.

SahAssar 3y ago
You're conflating complex and hard. Cloud functions might be easy, but they are also complex, and there are definitely specifics you need to keep in mind when developing them.
- jupp0r 3y ago
  There's a lot of complexity in the stack that makes a web server run. Nobody would suggest designing their own chips to do so. People insist that cloud computing is adding complexity when it often is a useful abstraction that allows companies to concentrate on the stuff that provides business value vs having to deal with lower levels of the stack.
- nailer 3y ago
  The sibling post already makes the same point, but I absolutely agree that serverless is specifically less complex than maintaining state for monolithic applications. Individually deploying endpoints in seconds is hugely beneficial. Likewise functional purity is easier to reason about.
tiew9Vii 3y ago
I find the actual deployment with cloudfunctions easy as you say. The complexity is the orchestration, the architecture, the hard vendor limitations, having to deal with being a distributed system. Having a FAAS service makes the deployment easy but development wise a traditional monolith deployed on static servers can be far simpler to deal with. I use FAAS (Lambda's /cloudflare functions) a lot for pet projects as it costs me fractions of a cent to host. The architecture is quite complex being distributed, dealing with restrictions, eventual concurrency etc etc. I find it enjoyable making things work in these systems basically for free but if these projects where a business with paying customers, alot of the stuff I'd drop from FAAS and deploy on static VPS servers as architecture is so much easier meaning I'm much more productive. With paying customers I can take the additional cost of a few VPS's or dedicated hosts such as Hetzner. The FAAS wouldn't outweigh the productivity gains.

matthewmacleod 3y ago

Not a great article but the underlying point has merit. My personal framework: - Always use containers, unless you can’t - Never use serverless, unless you must And above all, regardless of what you choose, keep the complexity to a minimum. Script and automate everything, eliminate manual processes, and never use two services when one will do. YMMV.

politelemon 3y ago

Discussing tech choices early on is always going to happen. You can try and be a purist and tell everyone to just talk requirements, but people are people, and requirements and tech are intertwined. An unreasonable requirement may suddenly make complexity balloon, but if early on it's spoken out loud that requirement XYZ is very difficult with technology ABC, it may emerge that the requirement was only a nice to have and can be lived without. So it goes both ways. There are still mitigations around this, just my opinion. So running in containers means you have a reasonable level of confidence that it can run in many places. How you run it in containers may make a difference. Standalone on its own represents a very small investment of overhead, but it's on a VM, still not terrible. k8s is a popular way to do it but is massive, and is not that different from a lock-in. Fargate and Container Apps take away a lot of that overhead and the lock-in is minimal, because you can escape to other kinds of hosting quite easily. I'd pick Fargate over the other choices where possible.

kristopolous 3y ago
I tackle this problem by focusing on building the product, not the infrastructure and making sure the first version works just for me. Once you hitch your wagon to anything you're along for their ride and have to make sure you can still do your own thing while wrangling your dependencies. So choose things that don't move very fast and don't ask much time from you

erik_seaberg 3y ago

Containers, like static linking, protect you from someone else’s platform if you can’t rely on it. But if it’s your own platform, why can’t you rely on it? Who’s maintaining it?

drpixie 3y ago
Best summary of containers - clear and hits the point.
pkulak 3y ago
Maybe you just want the ability to run on any platform.
nailer 3y ago
> But if it’s your own platform, why can’t you rely on it? Who’s maintaining it? I don’t know if this is a rhetorical question. You are now responsible for maintaining your custom environment. Obvious reasons why you can’t rely on maintaining your own platform include a lack of time for maintenance, a lack of understanding of the platform you have built, and a lack of prioritisation compared to other requirements. A huge amount of the value that senior admins provide is simply stopping junior and mids from building custom platforms usually because they’re excited about a technology rather than aware of the wider picture.
- WJW 3y ago
  > a lack of understanding of the platform you have built There is also the common extension to this problem: someone else built this platform some time ago and has long since left the company.
  - nailer 3y ago
    Yes exactly! Or “this has a bug, is only understood by one person and he’s busy right now”.
- erik_seaberg 3y ago
  Yeah, when I say “our own platform,” I’m thinking something like “we run Debian bullseye 11.7 in prod, build a .deb for that.” Starting our own unique distro in a Docker container is not a good use of time.

getoffmyyawn 3y ago

For me, a technology itself isn't a red flag. Not being able to explain the reason for choosing one approach over another is a big red flag. Or if the reason is "I want to try this new thing" and not "Our standard production stack won't work for this because (valid technical reasons)" that's a huge red flag.

rbanffy 3y ago
Some combinations tend to be red flags. Most Windows server setups are, for instance. I find it alarming to see PHP or Django applications deployed on IIS. There are some situations where Windows may be the best answer - compliance and fleet management, for instance - but unless you are running a Microsoft app that requires (or works better with) Windows, it is a lot of extra attack surface. I would be immediately suspicious of an IBM mainframe or an IBMi lying directly exposed on the internet as well. I know web servers run under IBMi and zOS, it’s just that it seems like a crazy choice - that’s not what those machines are designed for. As for that being a red flag rather than a suspicious choice, my attitude is always to find a reason for it - just assuming idiocy is both unkind and arrogant - there may be valid reasons for the craziest choices. As an aside, in the late 90’s a Brazilian ISP and portal went proudly with Novell’s Netware. They died without a trace after numerous outages and nobody was really surprised. If you are doing something nobody else is doing, you are either crazy or very clever and the odds are almost never favouring clever.

nailer 3y ago

If the company isn’t a cloud provider and they have their own k8s installation.

1attice 3y ago

This article feels like it was written by a disaffected '00s developer who misses Capistrano. The point of this article is to associate containers (a foundational technology) with "severless", which peaked as a search term back before the 19 in COVID19.