AWS ECS In Your Path To Serverless

The importance of AWS ECS can’t be understated as a step in an organization's journey to serverless. We're seeing this more clearly as we talk with increasingly more startups looking for infrastructure and AWS direction.

We can’t walk into startups who are just first addressing infrastructure issues and tell them the solution to their problems is to re-architect their stack and adopt a new cloud engineering paradigm. That approach is regularly met with skepticism that leads to the end of the conversation. For these situations, AWS ECS provides a perfect half step to cleanup the infrastructure and set them up for later serverless adoption.

The Problems We Are Seeing

The problems we see in startup infrastructure are usually very basic. For example:

• minimal environment separation
• hand built EC2 instances
• inadequate CI/CD pipelines
• production services failing

I have repeatedly said to people, "Do you want to spend months setting up Kubernetes or just go serverless?" But in reality there is no "just go serverless". It’s "spend months rewriting your stack to go serverless". Either option you choose, you spend months with existing lingering problems.

NOTE: It's as possible to go serverless in a few days or weeks as it is to deploy Kubernetes in a few days or weeks. Doable with the accumulation of subprime technical debt.

What matters more than our theories on the superiority of serverless is solving actual customer needs. When we talk to potential customers, often maturing startups, they mostly fall into one of two categories.

1. They have infrastructure and operations pains they want solved
2. They have infrastructure and operations pains they want solved with Kubernetes.

The second category has already decided on the technical solution and self-selected themselves out as a fit for us. We have other companies we can recommend to help them.

The first category however has not selected a technical solution and looks to us for guidance. For many of them the idea of rewriting their stack is unappealing when simpler alternatives exist. And even if we can convince someone to rewrite their stack we've asked a customer to ignore an iterative approach to solving their problems which is a core tenant we preach with a serverless approach.

How We Are Solving Them

Large projects might work in large organizations. But we can’t ask a startup to have its developers spend too much time moving the company laterally with a re-architecture instead of moving forward. So what we’re doing with startups is:

• segregating environments
• cleaning up access controls
• building CI/CD pipelines
• replacing services on EC2 with containers or a serverless replacement on a service by service basis

All those services running on EC2 instances, we’re identifying the best fit to move them to. Some will just be moved into containers. Some will be moved to Lambda. It all depends on what makes sense in terms of labor and payoff. We focus on meeting the organization's immediate needs. Serverless is used where appropriate and is seen as a long term goal overall.

Once we achieve a steady state, then we talk expanding the serverless footprint. It’s not about the technology, it’s about the customer and their needs. You employ us not for the technology but the ability to best address your needs.

Customer Needs Over Technology

As a company, ServerlessOps meets people where they are today and solves the problems they currently have. The long term value a customer receives is being taken in a technical and organizational direction that has better pros than the alternatives.