Hacker News Reader

This has been my experience 100%. It's super tempting at first, with 1,000,000 free invocations per month, plus paying for compute at the microsecond scale.

But then you run into all of the problems you've outlined, plus, the tooling process for CI/CD to serverless isn't so great (even with frameworks like Serverless Stack).

That being said, I'm personally excited about the managed Kubernetes offering AWS recently announced. The idea of being able to build my own containers and then just have AWS manage them based on pre-defined configuration I've given them is a lot better than the smoke-and-mirrors Lambda gives you today. For example, how can I tell how many Lambdas of mine are running concurrently? How many are warm or cold? There's lots of visibility lost in Lambda as it is today (not to say they aren't working on improving it).

> That being said, I'm personally excited about the managed Kubernetes offering AWS recently announced.

Another alternative for managing containers on a cluster of machines is AWS ECS. It has been around for a while and integrates really well with other AWS services (e.g. Cloudwatch, ALB). Unlike Kubernetes the scheduler is proprietary, but the agent running on individual instances is open source.

We've been using ECS for a while together with Terraform for managing the whole infrastructure in immutable and declarative way, and it has been great so far.

I've used both, and ECS was definitely the bigger pain. I deployed to and managed an ECS cluster for 8 months; the lack of replicability locally (which sucks for testing and CI/CD), the opaque and limited management options, and the lack of community interest / discussion all turned us off.

I think hosted kubernetes was easily the better option for us.

I agree, hosted Kubernetes is what serverless should have been. The current idea of serverless is a weird, restrictive bandage patch solution designed to hook and trap users.

It's only popular because Amazon has poured probably billions of dollars into it and have lobbied their way into many corporations.

> In general, serverless computing tasks cost 100-1000× more per cpu cycle than a counterpart running on a cloud server.

Citation needed. With Serverless you have to do zero system administration, patching, maintenance, security hardening, etc.

In the early 1900s, cars required tons of maintenance. You had to hand crank the engine to start it, and if you went on a long trip, you needed to bring along a mechanic, as your car was likely to break down. I know it's tempting for engineers like ourselves to believe we can do system administration better than Amazon, but it's just not true. Do you think automobile owners long for the days when they had to hand crank their engine to start it, and do maintenance just to travel 100 miles? In a decade or two, the idea of doing manual system administration, load balancing, scaling, etc, will be just as archaic.

>> With Serverless you have to do zero system administration, patching, maintenance, security hardening, etc

That is assuming that the system is ready and no further changes need to be made to it. Every time changes are made, deployment of new features do still require administration and security checking. But pretty much the same can be said about non-serverless tech stacks. If you don't make changes to the system then a single person can administer a potentially huge system.

The reality is that systems constantly need to change so serverless doesn't actually add much value and it takes away something very important: Flexibility.

I'm talking about all the lower levels below your code. Of course, you need to do something to upgrade your code, but when was the last time you ever had to SSH to your Lambda function and install an OpenSSL patch due to a security vulnerability?

Nearly every trucking firm I've worked with has their own in-house shop, with mechanics and everything. Turns out, outsourcing the maintenance of vehicles that experience tens of thousands of miles every quarter is more expensive than just paying your own people to do it. Same with municipal fleets. Same with taxi fleets.

There are many variables that enter into a cost-benefit calculation when thinking about this. But what it really comes down to is Scale. Projects on the low end of scaling will find it cheaper to outsource everything they can. But at higher scale? Think about it like this: Instead of building their own data centers, does it make sense for Amazon or Google to just colo space in other people's data centers to build AWS or GCP? Of course it doesn't.

So, those are the bounds of our "scale scale". At some point it becomes cheaper to move off managed products and onto VMs in the cloud. At some point after that, it becomes cheaper to deploy your own metal. The challenge companies need to solve is determining where they're at, and cost-optimizing parts where they can save money. A great example is Netflix; they're nearly totally on AWS, but they've cost-optimized their CDN significantly to save money on bandwidth by getting out of AWS.

QoS is another consideration. Deploying your own metal is hard, and the quality of the service you provide might degrade. But don't marginalize the other end of that scale; there are QoS downsides to going full managed like with Lambda. Its another variable to consider.

Lambda -> EC2 is the same kind of cost-optimization movement, just further down in scaling. At some point Lambda will become too expensive. Then, you'll probably want to move to something like managed Kubernetes/ECS, which has almost no administrative overhead compared to just EC2 instances but still makes scaling relatively easy.

I agree that you need to make the right decision depending on what scale you are at. The reality is that most companies are at the scale of a small shop, and it would be better (total cost of ownership) to use Amazon's highly automated services.

However, every sysadmin I've met (and I used to be one) would like to think they are managing Walmart's trucking fleet, when the reality is they are more like Joe's local furniture delivery.

One other thing to mention - truck maintenance still requires human technicians - we haven't automated it yet so that robots could do it, but system administration most definitely can be automated at Amazon scale.

> With Serverless you have to do zero system administration, patching, maintenance, security hardening, etc.

Sounds like "serverless" is just a new buzzword for shared hosting, with all the same downsides plus increased vendor lock-in.

I've seen analogies drawn with CGI.

I do technical agile coaching and I’m telling you not only will Serverless be successful in the enterprise it’s going to take over.

1. Enterprise systems are always Rube Goldberg machines. Serverless is perfect for this. Check out the 12 Serverless architectures talk at reinvent.

2. Most enteprise IT shops completely missed containerization. Many are still struggling to adopt the public cloud. The feet dragging and lip service by IT Infra and Security regarding public cloud is real.

3. It’s easier to give someone permission to use lambda than EC2. Thus teams follow the path of least resistance. Infra really fucked up in a lot of shops by allowing lambda but feet dragging on EC2. Teams are skipping over the whole containerization and devops mindset and just going with serverlesss. I’m seeing it happen in my F 500 clients. Teams are designing around lambdas because they know they can get their apps provisioned and deployed easily. Remember bureaucracy is enemy #1 of success so anything that circumvents it will become a well worn path.

A bit more:

* Everyone talks of serverless as FaaS or single-file, but most people are not writing single-file contained applications. They are depending on the ecosystem of the language they are using, which means using npm/maven/rubygems/pypi libraries. The dream of merely uploading a single file with a function is just not true, folders have to be hoisted up, packages/dependencies have to be installed and isolated per-function. Buildpacks are there for a good reason.

* Pay-per-request sounds fun until you run into scale. Why build an application that nobody uses and optimize it to remain unused? What happens to business continuity when it receives a huge surge of traffic and runs out of budget? Granted yes, we're talking about idle billing, but anyone running applications at scale - the benefits of having 1-2 always-on, always-budgeted containers completely overwhelms idle billing when it comes to per-request pricing and business continuity.

There are always tradeoffs with any technology. The article comes across as trying to sell unicorns, which is not healthy. It must be more transparent with the bad/ugly sides when trying to cover "serverless in 2018".

All of these points are the exact same concerns I've had with serverless. The higher cost per CPU cycle, plus additional engineering cost managing all the functions and build processes seem better spent deploying on a dedicated server. For all the hype around serverless in 2017, I would love to hear from someone explaining why it's not just hype, and something valuable to developers as more than a side tool.

Not disagreeing with your point, but it's important for a new project to consider the human cost of ops in addition to the cost per request.

Lots of "enterprise" solutions don't need more than a few hundred TPS and can tolerate some of the variability that comes with lambda. The net cost (including ops work) will likely be less in these scenarios, plus they don't have to staff for a devops guy or pay to build that skillset up internally.

I've used lambda in two medium sized projects. One was a full webapp with the API Gateway/Lambda/Dyanmo serverless stack, which worked very well (with a few caveats; local testing is hard, but it's totally feasible to spin up a whole new environment for each PR and run tests in it). The other was a sort of distributed workflow engine. One EC2 instance housed long-running processes (think JDBC connections that needed to stay open) and the rest of the infrastructure handled a load of async events, piping data around through SNS channels. Pretty easy and very slick once you get the hang of it.

Definitely needs better tooling, though I think that'll come along in time.

One thing that hasn't really been covered as much but does seem to get some interest with Enterprises (that I've spoken to) is being able to understand the cost of business in more detail. As the unit of deployment shrinks (monolith -> micro service -> function) the visibility increases.

I can see that function X costs $Y per invocation and a whole business process comprising of a particular set of functions is going to cost me $Z. With that sort of granularity an architect can give better estimates for new projects or optimising existing. It may even lead to non-technical members of the business building processes by connecting functions together (like AWS Step functions?)

With a marketplace or "Function Store", the code can be switched out for something more efficient or more feature rich. eg. a new image recognition function that improves accuracy at the same time as decreasing execution speed (charged by the author only 1% more per invocation than the previous code).

Its still early days and a lot missing to get to this point (the marketplaces, common APIs, better granularity for things like databases - eg. per row billing) but it can be a compelling vision for Enterprises to get a more accurate idea of the cost of business.

Microservices (and monoliths) should be able to head in the same direction with advanced tracing and operational metrics. Ultimately I think there will be a combination of all three types of architectures rather than a single winning architecture. All of the approaches will need to lead to a better understanding of the costs involved in building and running code. Functions may be slightly easier to achieve that visibility.

You can just run your own serverless cluster and get the exact same price as non-serverless.

Agreed, I was referring exclusively to managed serverless services. I'm not a big fan of managed anything over the virtual server level (which I can't argue with).

Genuine question, isn't BigQuery like services serverless? If yes, I don't see a problem with Enterprise adoption.

Yeah say you do most of your processing in the client but need to sync local storage to a server for persistence and then may need to re-hydrate that state later, those can be run in the background with a service worker where the slowness doesn't affect the other parts of the application.