By: Tyler Auerbeck (@tylerauerbeck)
Edited by: Ben Cotton (@funnelfiasco)
Thank you everyone for joining us today. We gather here to say our goodbyes to our dear friend, Localhost. They’ve been there for us through the good times, the bad times, and the “we should really be sleeping right now…but let me just try one last thing” times. They’ve held our overly-complicated terminal configurations and—in all likelihood—most of our secrets. But alas, it is time to let our good friend ride into the sunset.
Saying Goodbye
But why?! We’ve all likely spent more time than we care to admit making these machines feel like home. They’re part of the family! Well, as it turns out, that can become part of the problem. We’ve all seen issues that are accompanied by the line “well it works on my machine” and a round of laughs. The problem with localhost is that it can be extremely difficult to ensure that a setup being utilized by one developer actually matches what is being run by another. This can happen for any number of reasons such as developer platform (Linux vs MacOS vs Windows), IDE (VScode vs Jetbrains), or even just the installation method of the tools you’re using. The different combinations of these problems only exacerbates the problem and likely leads to (at a minimum!) hundreds of hours of lost productivity. All in the name of working locally. But what if there was a better way?
My Machine is Your Machine
With everything becoming Cloud Native these days, why do we want to treat development any differently? The common trend recently is to push a number of our workloads into containers. Why? Because with containers we have the ability to bundle our runtimes, tooling, and any additional dependencies via a well-defined format. We can expect them to run almost anywhere, the same way, each and every time. What if we took that same approach and instead of a web application, we shipped our development environment?
Well, as it turns out, this is exactly what a few projects are starting to give us the ability to do. Now instead of shipping complex Makefiles, multiple install scripts, or having to ask our users to pipe our mystery scripts into bash, we can simply just launch our development environments out into the cloud of our choice. Currently, there are two main projects that offer us this functionality. If you’re not interested in hosting anything yourself, GitHub Codespaces is a hosted solution that integrates directly with your codebase and allows you to easily spin up a VScode instance to get to work. However, if you have more specific restrictions or just prefer to run your own infrastructure, another project offering this functionality is Eclipse Che. Whatever solution works best for your situation is fine. The more important part of both of these offerings is _how_ they make these environments available to you.
Development Environment Specs
Both of the above offerings allow you to specify the dev environment that you want to make available to your users/developers. It’s important to note that this is done on a per repository basis because there is never going to be a single dev environment that works to run them all. This is exactly the mess that we’re trying to get out of! We want to be able to define an environment that is purpose-built for the specific project that we are working on!
To do this, these platforms give us configuration files: dev-container.json (GitHub Workspaces) and devfile (Eclipse Che). Although the specs differ between the two formats, the underlying principles are the same. Within one well defined configuration file, I am able to specify the tooling that needs installed, an image that should be used or built to run all of my development inside of, ports that need exposed, storage that needs mounted, plugins to be used, etc. Everything that I would usually need to configure by hand when getting started with a project now _just happens_ whenever I launch my environments. So now not only are we solving the _snowflake_ environment problem, but we are also saving valuable time because the environment will be configured and ready as soon as we click launch. It’s just what we’ve always wanted: push button and get to work!
What Problems Are We Solving
This all sounds great right? But you might be shaking your first in the air and screaming “Just let me use my laptop!” While this is absolutely something that I can empathize with and may generally work on personal projects, there are real problems that are being solved with this approach. I’ve seen this more specifically in enterprise development shops where _your machine_ isn’t really *your* machine. Which brings us to our first problem
Permissions
Given the current security environment, most enterprise development shops aren’t too keen on giving you the permissions to install any of the tooling that you actually need. I have seen developers lose weeks waiting on a request to just install their runtime on their machines before they’re ever even able to begin contributing to their time. Multiply that by every tool and dependency that they might need and you can imagine how much valuable and productive time is lost in the name of security and process.
By moving to a cloud native development approach, your development environments can be treated just like any other application that you run and scanned/approved by your security teams. When a new developer comes on board, they can get right to work! No more waiting on approvals/installation because this has already gone through the necessary pipelines and is just ready whenever you are.
Develop In Production
Alright, so maybe we shouldn’t develop *in* production, but rather in an environment that is _like_ production. By developing an application in a location where it will ultimately be running, you get a better feel for configurations and even failure modes that you otherwise may not experience by developing solely on your local machine. Expecting certain ports to be available? Need specific hardware? By ensuring your configuration files mirror your environments you can determine these problems earlier on in your process versus finding them once they’ve launched into a staging or production environment. This ultimately helps you reduce downtime and speeds up your time to resolving these problems as you may find them before they’re ever even introduced.
Localhost: Still Slightly Alive
Realistically, this isn’t going to be a solution for everything or everyone. There are workloads and development tasks that require specialized environments or are potentially just not well suited to being done inside of a container environment. And that’s okay! There are still other approaches to finding a way off of your local machine and into the hearts of all of your developers without having to have them sink their time into troubleshooting differences between each of their machines. The heart of the problem still stands: developers want to get to work and provide value. Being able to provide on-demand environments that encapsulate all of the requirements of a project so that they can get involved immediately helps drive this productivity for both your teams and your communities, all without having to burn hours troubleshooting a personal machine.
So for now, let us lay our dear friend Localhost to rest. They may no longer be with us, but have no fear! Our localhost will always be with us up in the cloud(s)!
No comments:
Post a Comment