Amazon EC2 Container Service

DevOps / Build, Test, Deploy / Containers as a Service
Avatar of ruswerner
Lead Engineer at StackShare

We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.

We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.

The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.

Avatar of undefined
Avatar of Startouf
CTO at My Job Glasses

We build a Slack app using the Bolt framework from slack, a Node.js express app. It allows us to easily implement some administration features so we can easily communicate with our backend services, and we don't have to develop any frontend app since Slack block kit will do this for us. It can act as a Chatbot or handle message actions and custom slack flows for our employees.

This app is deployed as a microservice on Amazon EC2 Container Service with AWS Fargate. It uses very little memory (and money) and can communicate easily with our backend services. Slack is connected to this app through a ALB ( AWS Elastic Load Balancing (ELB) )

16 upvotes129.2K views
Avatar of undefined
Avatar of deepshah22
Software Engineer at Amazon

I only know Java and so thinking of building a web application in the following order. I need some help on what alternatives I can choose. Open to replace components, services, or infrastructure.

  • Frontend: AngularJS, Bootstrap
  • Web Framework: Spring Boot
  • Database: Amazon DynamoDB
  • Authentication: Auth0
  • Deployment: Amazon EC2 Container Service
  • Local Testing: Docker
  • Marketing: Mailchimp (Separately Export from Auth0)
  • Website Domain: GoDaddy
  • Routing: Amazon Route 53

PS: Open to exploring options of going completely native ( AWS Lambda, AWS Security but have to learn all)

5 upvotes25.9K views
Replies (2)
Avatar of plakhlani
Founder and CEO at Facile Technolab Pvt Ltd

I would recommend to upgrade your stack and consider Angular.

Also, if you are working with docker, instead of manually managing your EC2 and docker inside it, switch to ECS as its free of cost and hassle free way to deploy and keep running your containers efficiently.

Good luck.

4 upvotes4.4K views

Instead of Docker , no doubt its great but it has vulnerabilitis and restricitions with dameon and root thread. I would pickup Podman. Also Ambasador is a culmination of Gateway LB and ServiceMesh on istio and Envoy. Great for both East-west and North south microservices communication, policy managment and security with Istio. Spring Boot is not a WebFW. For platform web fw one can use Reactive like SPring WebFlow rather than Spring MVC. For java experience, Spring provides great assets.

I will switch to using Kubernetes whether managed or custom depends on several factors rather than AWS ecs. For LB Amabassador is a great alternative on AWS. One can simply use this on top of ECS clusters. Instead of running in to different frameworks one can simply use one FW at both client and server side for consuming and SSE. I believe one can look at Lot of it depends what you need a full FW or a light librarry like React to be part of V in your MVC. Whether you need a SPA , on Mobile etc... in that case KOTLIN is also another option on Java. Dont go with Android. Best luck. Swapnil S

3 upvotes3.3K views