- Software Development
- Kubernetes from Day One? – InApps 2022
Kubernetes from Day One? – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Kubernetes from Day One? – InApps in today’s post !
Read more about Kubernetes from Day One? – InApps at Wikipedia
You can find content about Kubernetes from Day One? – InApps from the Wikipedia website
When you hear the word “Kubernetes” what are your first thoughts?
Chances are, the word “complexity” is among some of the first words that come to mind, if you’ve been privy to the general conversation around our favorite cloud native container orchestration system. As such, your first instincts when building a new application may not include the idea of building for Kubernetes — just keep it simple and build an MVP based on the customer’s needs, right? — but the folks over at StackOverflow have put out a blog post this week arguing for why you should build on Kubernetes from day one.
The @StackOverflow engineering team runs one of the most heavily trafficked sites on the Internet. So, I listen when they have opinions on Infra.
Here, they say it’s a smart idea to build on Kubernetes from day 1 … https://t.co/UXrYia4Oh9
— Richard Seroter (@rseroter) July 22, 2021
“If you’re a developer at an enterprise, you want to make sure that you’re meeting the expectations and needs of the business. Operating at scale is, at best, a tomorrow problem,” they write. “If you’re building a new app today, it might be worth taking a closer look at making it cloud native and using Kubernetes from the jump. The effort to set up Kubernetes is less than you think. Certainly, it’s less than the effort it would take to refactor your app later on to support containerization.”
Now, if you’ve ever attempted to set up and run Kubernetes yourself and run face-first into that steep learning curve, you might be thinking something along the lines of “hell no” right about now. Their solution is simple, of course — simply handoff that part to your favorite giant cloud provider by using their managed Kubernetes service and, voila! From there, the folks at StackOverflow simply see the future-proofing benefits, the ability to be “(somewhat) cloud-agnostic,” and the ability to use Kubernetes to quickly spin up new environments, enabling a GitOps type of workflow.
For the skeptical, two other blog posts from recent weeks also come to mind. First, Ably writes that “no, we don’t use Kubernetes,” arguing instead for a combination of AWS services to handle all of the scaling and complexity.
“To move to Kubernetes, an organization needs a full engineering team just to keep the Kubernetes clusters running, and that’s assuming a managed Kubernetes service and that they can rely on additional infrastructure engineers to maintain other supporting services on top of, well, the organization’s actual product or service,” they write.
While this is part of StackOverflow’s reasoning — “The effort to set up Kubernetes is less than you think. Certainly, it’s less than the effort it would take to refactor your app later on to support containerization.” — Ably argues that “it seems that introducing such an enormously expensive component would merely move some of our problems around instead of actually solving them.”
Meanwhile, another blog post this week argues that Kubernetes is our generation’s Multics, again centering on this idea of complexity. Essentially, the argument here is that Kubernetes is “a serious, respectable, but overly complex system that will eventually be replaced by something simpler: the Unix of distributed operating systems.” Well then, back to Unix it is!
Surely, none of the arguments made here are going to be the make or break of your decision around Kubernetes, but what do you think? Will you be building your next application for Kubernetes from the ground up? Or, like Ably, do you think the juice is not worth that complexity of the squeeze?
+1 for grouping similar topics pic.twitter.com/6ejZqpY9uq
— Molly Struve (@molly_struve) July 21, 2021
This Week in Programming
- The CI/CD Abuse Continues: This week, it’s Atlassian’s Bitbucket that has said it needs to make some changes to Bitbucket Pipelines due to crypto mining abuse. It’s a trend that has left few stones unturned, it seems, as we’ve already written about Docker shutting down free access to Docker Hub Autobuilds, as well as TravisCI limiting access to builds for the same reasons. Now, it’s Bitbucket’s turn to fault the recent “massive increase in abuse from bad actors taking advantage of the free minutes to mine cryptocurrencies.” In Bitbucket’s case, however, those changes don’t mean the end of access, but rather the requirement for new Bitbucket Cloud users to use two-step verification. Existing paid teams will be exempt and can continue as they were. Already, the company says it has worked on enforcing quotas and “reducing the existing grace period for free-tier users,” as well as working to automatically detect and terminate abusive accounts and their pipelines.
- Rust 2021 Goes Into Public Testing: For those of you who want to be on the bleeding-ish edge of Rust, now’s the time, as the language team has announced the beginning of the Rust 2021 public testing period. The Rust team says they are “encouraging adventurous users to test migrating their crates over to Rust 2021” and has provided a short set of instructions (or more detailed directions as needed) for those who wish to move over to the admittedly unstable version of Rust. “All of the planned features for the edition are now available on nightly builds along with migrations that should move your code from Rust 2018 to Rust 2021,” they write, pointing potential testers to the nightly version of the Edition Guide for all that’s new in Rust 2021. If you do decide to make the leap, they also suggest doing so by migrating your crates in a temporary copy of your code versus your main branch, just in case.
programmers sure do love not shutting the fuck up about DRY code
— Kat Cosgrove (@Dixie3Flatline) July 17, 2021
- Visual Studio 2022 for Mac: The private preview of of Visual Studio for Mac is open, bringing with it the first release of the .NET IDE with a “refreshed, fully native macOS UI.” In case you’re hesitant to commit, know that it can be installed side-by-side with earlier versions, so feel free to sign up now. The Visual Studio team writes that their “goal with Visual Studio 2022 for Mac is to make a modern .NET IDE tailored for the Mac” and so focuses on improving IDE performance and reducing crashes, taking advantage of more of macOS’s built-in accessibility features, and updating the experience to feel more familiar between Mac and Windows. The biggest changes, it sounds like, come with the new native MacOS UI, which they say “affects every part of Visual Studio for Mac.” The move will fix more than 100 issues related to performance, reliability, and product quality, as well as improve how the IDE works with macOS’s built-in assistive technologies. Visually, changes include a footer status bar, a new tab model for documents/tool window, and refreshed light and dark themes. Changes don’t stop with the looks, though, and users can expect to see some changes in menus and terminology to make it easier for users coming over from Windows. Finally, the new Git experience that was recently added to Visual Studio will also be joining the Mac version, starting with the Git Changes tool window.
It is a privilege and a responsibility to be a software developer.
it is a privilege because we are in a position to change the world.
It is a responsibility because we are in a position to change the world.
— Grady Booch (@Grady_Booch) July 21, 2021
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Ably, Docker.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.