31–40 of 116 posts
Earlier quoted context omitted.
> eat the frog Eat the frog? Which language is that? The expression sounds really cool! Most of the time in English I've encountered "bite the bullet".
Have you heard of Mark Twain by any chance? People say he used to write in English.
And I actually read many of Mark Twain's works in Romanian, so, oh well... ¯\_(ツ)_/¯
I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…
Earlier quoted context omitted.
Could you comment on why you are moving away from elastic beanstalk? We manage a fairly simple EB deployment but it seems perfect for our infra needs, and I'm not able to imagine why we might need to scale out of it - if any other services are required, I'm tempted to only launch multiple EB deployments instead of going the kubernetes/fargate route.
Largely I don't think it's worth moving off EB except in specific scenarios. I'm a Rails monolith and DB migrations are not well suited in ElasticBeanstalk when running docker containers. There's no way to run a single container that 'completes' and then returns whether it was successful or not. Currently I have a separate environment that holds a single EC2 (lots of idle time) to run migrations. It fires and the dep…
I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…
I highly recommend the CDK here. A setup very similar to yours is just a few lines of code which you can synth into cloudformation templates
I feel CDK has the mix between optional granularity & high-level constructs just right, while this plugin looks nice for a quick MVP standup i'd be surprised to see it in use for production workloads
Earlier quoted context omitted.
In my opinion, being cloud-agnostic is today’s being database-agnostic. In more than two decades of professional software development, I have only once encountered a situation where an existing application was migrated to a different RDBMS instead of just being rewritten. Using an ORM framework for the sake of database independence seems hardly justified in that case. I suppose that things will turn out much the same…
I mostly agree with you but we definitely reduced reliance on AWS specific functionality after starting to offer on-premise software installations. Most of them don’t gain you THAT much and then the software really isn’t very portable.
There must be a better way of doing all this.
On a different note, recently I was looking to learn AWS concepts through online courses. After so much of research I finally found this e-book on Gumroad which is written by Daniel Vassallo who has worked in AWS team for 10+ years. I found this e-book very helpful as a beginner.
This book covers most of the topics that you need to learn to get started:
If someone is interested, here are the links :) Single License: https://gumroad.com/a/238777459/MsVlG Team License: https://gumroad.com/a/238777459/EpUED
I highly recommend buying this e-book if you think AWS documentation is overwhelming.
None of this is simple. We're drowning in YAML files. It's difficult to maintain. Jinja + ansible + helm... it's a joke. There must be a better way of doing all this.
I expect to finish the remaining work in the next few weeks. Can I contact you to try it out? (My email is on my profile)