Red Hat has always given operations teams value in deploying Red Hat Enterprise Linux (RHEL), and that's no different in a containerized world. But, as a developer, why should I build on RHEL? Does the underlying operating system really affect me?
It might if you want to:
- get your app to production faster
- work on new products, not maintain old ones
- avoid compatibility issues at scale
(And yes RHEL is available at no cost for development use.)
1) Take Your Containers to Production - Faster
You want to build your application, but there’s nothing better than getting users. To get users, your application has to be deployed in production.
Take your application to production with efficiency and confidence. There is nothing worse than thinking your application is going to production, only to find out there is a snag - your container doesn't meet operational readiness checks :-(
Build your containers on Red Hat Enterprise Linux from the very start of your project. Instead of having to make last minute changes to help operations port your application to their production platform, go home for the weekend. When you get back Monday, operations will be happy (that's rare) and tell you the deployment went flawlessly (that's also rare --- in the voice of Jack Black) ;-)
2) Your Container Legacy - Work on the new projects
Your code becomes legacy the minute you deploy it to production. Don't worry about support problems five years from now when you should be focusing on new projects. Hand support off to operations. The best way to do that is with Red Hat Enterprise Linux.
Your code can run stably for 10 years. With a 100% backward compatible patch stream, operations won't be calling you to make code changes because of patch compatibility problems, security vulnerabilities or performance regressions. Operations also won't have to call you for help when they decide to move your application to a different cloud (e.g. to save money) or new hardware (e.g. because it's old). As a developer, you can focus on new products, not old problems.
3) Mo containers, Mo problems - Scale it up
Microservices built in containers makes collaborating with other development teams easier. Focus on only your services and let other teams focus on theirs. But, more services, means more containers that operations has to manage in production.
Don't throw hundreds of different containers over the fence and hope for the best. Build each of your service containers on RHEL and don't get bogged down helping operations troubleshoot upgrades, performance regressions, or platform compatibility issues at scale.
Help operations have your back - by giving them one less thing to worry about. With thousands of containers scaling up and down in real time you can be sipping Caipirinhas by the pool while operations is calmly managing Kubernetes ;-)
Conclusion
Don't collect technical debt that you will have to pay for down the road. Let operations handle production while you focus on new applications.
Build your new application containers on Red Hat Enterprise Linux so that you can hand operations problems off to operations. Ain’t nobody got time for porting old applications and troubleshooting containers in production.
Also, drink a Caipirinha for me - you're welcome (for the new drink and the advice) ;-)
Last updated: September 3, 2019