Better User-Experience to the Cloud Deployment
For quite some time, consumer cloud services have been easy to use: users don't need to think about where the files are or how to share them. Unfortunately, developers haven't had this luxury. Sharing the product under development is still a bit cumbersome. A lot of focus has been put to the scaling, but for many . In this blog post, I'll share what I think is wrong with the current solutions and how they can be simplified.
Current deployment experience in AWS, Azure, and Google Cloud
If you want to host a third-party application (such as a blog) or demonstrate your software to a client, what do you need to get the application up and running in the cloud?
I have working source code on my laptop and I want to make it public. The classic approach would be to buy computing time in the form of a virtual machine instance from Azure, AWS, or Google Cloud Platform.
Setup may be something like this:
- create account
- add billing information
- search for the appropriate service (EC2, Google Compute Engine, Azure App Service)
- create an instance
- name the instance
- choose geo-location
- choose the size of the instance
- (create GitHub account)
- (create repository)
- (if the source code is on GitHub, you need to authorize the cloud provider to access the GitHub account)
- push code
- check deployment success
Optional steps are in parentheses.
You can complete many of the steps at the command line after you have installed the proper tools.
When I look at this list, the process seems too complex for the simple task of publicly releasing an application.
One step forward
Many providers stand on giant's shoulders, providing their best service with particular successful languages or platforms. Heroku, for example, runs on top of AWS and allows easy deployment management by providing pipelines (dev -> staging -> production), rollbacks, user-friendly command line tools, etc. The learning material is written to cover common use cases.
There are clear instructions for deploying Node.js projects.
The checklist includes the following steps:
- create a Heroku account
- install Heroku Toolbelt
- log in to Heroku using Heroku Toolbelt
- modify existing Node.js application
- create a new instance using Heroku Toolbelt
- push source code directly to the Heroku Git repository
- make sure that the application is running using Heroku Toolbelt
Modifying the Node.js app requires creating a Procfile or using npm scripts to start the application.
The process is quite straightforward, but it could have less steps.
Publish buttons
Heroku was first (the first that I noticed, at least) to make an HTML button for provisioning an environment for an application. The Heroku Button can provision Dynos (Heroku virtual machine instances) and third-party services like MongoDB databases. Other service providers have adopted similar one-click deployments (for example, Microsoft Azure's Deploy to Azure button).
I have found these extremely useful when I want to try, for example, the Twitter real-time stream using Node.js or the Ghost blogging platform on Azure. Experimenting is more gratifying when you start with a working environment.
The experience could be better, though. Let's take Azure Ghost for example. This is the wizard's first step.
Many of the options are offered too early. Site Location: Who cares at this point? The whole point of the cloud is that I don't have to worry about where the server is located. Resource Group: You need to know how Azure structures resources, making this more difficult than it should be. Directory and Subscription: Microsoft, please just put it somewhere and I'll figure it out later. SKU: Of course everyone who is trying something new wants to start with free service and change it later.
I would like to see the service create free versions of each required service after asking for credentials. Later, the user could move them to different subscriptions, locations, etc.
When I said that many of the options are offered too early, I actually meant that every option is offered too early.
Going forward
A company called Zeit created an impressively straightforward Node.js deployment with their service, now.
The lack of prerequisites is compelling:
- No need to install git or source control
- No need to set up keys
- No complicated cloud provider setup or registration
The features include internal multi-cloud solution, which means that, true to the nature of cloud infrastructure, the server farm running your software is abstracted away. Your software may be deployed to the Amazon virtual machine today and deployed to another provider tomorrow.
As soon as you type now, we give you a URL that you can go to or share with co-workers and collaborators. -Zeit.co / Features
Interestingly, there isn't any project-specific now configuration.
Let's see how this works in practice.
I randomly picked an open source Express example, and the lucky winner was Shapeshed's Express example.
Unrelated to now, I started by making a pull request because the package.json was invalid.
I installed now globally (npm install -g now), then registered and authenticated myself with the command now. Registration may sound like a cumbersome process, but it is very simple:
After providing an email address, I got an email with a link:
After I clicked the verification link, the process automatically continued:
My clipboard then contained a URL to the published site.
Voilà!
Many of you may already be thinking, sure, deploying an example or tutorial is easy, but what about my microservice architecture solution with 128 instances and several types of databases? I'm sorry, but I don't have an answer for you.
The simplicity of the now is a bit mind-bending when thinking of maintaining a large application with multiple developers. I am not worried about performance, but team size or instance count can bring challenges. If you have experience on this, please comment on Hacker News.
Conclusion
I have deployed software in many ways: manually installing files transferred via a crappy GPRS connection, one-click deployments using various languages and platforms, etc. Each year, the deployment experience has been better. Experimenting with now was like a breath of fresh air; in most cases, existing solutions are overkill when you just want to deploy something simple.
I would like to see similar solutions for languages other than Node.js. Maybe I haven't heard about them. Let me know if you have found any interesting solutions.