How Containers Can Help Non-Developers in Your Business
It’s easy to see how containers can help your developer team. But they’re also useful for people across your business, including developer relations, marketing, and technical documentation.
Being able to deploy any version of your app across any platform means that your technical writers can write about new features easily, your marketing team can get to grips with new product features quickly, and your developer relations team can demo your app with confidence.
It’s no secret that there’s a new product thought up every second. That’s why it’s more important than ever to make sure that you find your audience quickly: the people who will use your product, love it, and advocate it. This is exactly what the people outside of your dev team are responsible for. So it behooves you to make their jobs as easy as possible.
Getting to Know Containers
In the past, getting a specific version of your app up and running a local computer might’ve taken half a day. That’s because apps usually have a lot of dependencies, as well as runtime environment requirements. Getting this stuff set up as a dev can be tricky enough. But expecting someone outside of your dev team to do it is usually a no-go.
As we covered in a previous post, containers make it easy to automate all of this. Getting any version of your app running locally can be as easy as cloning the right branch of your repository and running make. This puts an identical copy of the app on each person’s computer, making it ideal for testing, QAing, documenting, and live demos.
Using containers like this (instead of a shared staging environment) means people can work individually, as and when they want, without placing additional burdens on the dev team to spin up new environments.
This will improve the efficiency and self-reliance of any team that works with your app, leading to quicker QA test cycles, quicker documentation, quicker marketing, and so on.
Containers for Developer Advocates
Developer advocates (aka evangelists) are changing the face of tech. Some days they might be coding beside you, other days they’re at a conference, showing off your app to potential customers and explaining how it works in detail.
To do this, your developer advocates have to get under the hood of an application and really understand it. In the past, this has meant complicated local setups, custom hosted beta versions of your product, red tape, delays, and hassle for your devops team.
If you’re using containers and you’re deploying to a PaaS like Deis, you can perfectly recreate your production environment on your local machine, with very little fuss, and without the resource overheads typically associated with vitual machines.
Imagine this: Sarah is part of your developer relations team. She’s at a conference, between panels. As she’s waiting for the next presentation to start, she finds herself in conversation with someone that’s never used containers. As they talk, Sarah is able to spin up a customized, ready-to-use version of her company’s white-label application. Inspired by this, she walks her audience through setting up Docker on their machines, showing them how to download the application image during her presentation.
After the panel, Sarah speaks with one of the customers from the audience who was impressed with the use of containers to host her company’s application. They inquire as to a particular feature, which Sarah has in one of her feature branch containers. She starts the container, showing the customer how the still-in-beta feature works in real-time. Impressed, the customer agrees to a follow-up call with the sales team.
How Containers Help Your Technical Writer
Using containers with Deis is also beneficial to your technical writing team.
Tech doc writers need to be able to quickly spin up any arbitrary version of your software and get it running right away, exactly like it would be in production.
Chances are, your app probably has multiple active versions that you support at any one time. Perhaps the current main line and its feature and bugfix branches. Plus maybe the past two previous major releases and their feature and bugfix branches. Then additionally, your active dev, alpha, or beta versions.
Imagine: Elizabeth—one of your technical writers—has a deadline due tonight regarding a patch to debug an issue. Rather than having to wait for a stable QA environment, she’s able to access the software as it would be live, in a matter of minutes, and without requiring any assistance from anyone else. This allows her to narrow in on the feature affected in the patch, giving her time to check both the client-side and back-end behaviour.
Containers makes this process a snap.
And because the same container can be used in development as well as production, on any machine that supports the container tech, you can be sure that the setup and function of your app is identical, across many different platforms, versions of languages, environments, and operating systems. Something that would’ve been next to impossible to do in the past.
Using containers also allows for easy rollback to a stable build, with the ability to view multiple instances of the same application to compare it side-by-side in real time.
Containers also allow for technical writers such as Elizabeth to quickly draft how-to’s, customer-facing solutions, and expand your application’s knowledge base in house rather than relying on a community hosted FAQ.
Marketing With Containers
Being able to move fast and get your message out there on time can often be critical to the success of your product.
Marketing teams are often asked to wait for access to a preview environment where they check out a new version of product for themselves, or even direct customers or potential clients. This can lead to frustration if builds are pushed back or shared staging environments are constantly in a state of flux. Worse yet, getting a shared environment spun up with a specific version of the app for marketing might involve a lot of red tape, or might just be a pain for the already swamped dev team.
Using containers fixes this problem by allowing anyone in marketing to spin up any version of your app, as and when they need it.
For people in marketing and public relations, this lets them try new features, prepare marketing materials, and start hyping new versions of your product. Containers allow your marketing team to get hands-on experience with your application at every stage of life, offering unique opportunities to write behind-the-scenes blog posts, pitching at conferences, and so on.
Because containers let you duplicate production setups locally, even remote workers with no connection can continue to work with your app.
Containers can also be a marketing boon in another way. If you’re running an open source project (or otherwise shipping source to your customers) and you want to attract more contributions, containers can can help. Someone is much more likely to contribute if getting the app running locally takes minutes instead of hours.
Using containers makes work and collaboration easier for developer advocates, technical authors, and people on your marketing team.
If you’re your app is containerised and running on a PaaS like Deis, it’s trivial to get a fully working version of your app running locally. This makes it easy for anyone in the business to collaborate with your dev team.
Spend less time worrying about shared staging environments, red tape, and causing hassle for your devops team--and more time learning your product, writing documentation, demoing your product, and getting your product in front of the people that matter.