Cloud Foundry zero downtime deployments

By Al
Software releases can be a very painful experience and typically involve some downtime, especially to traditional monolithic applications. As we have seen in previous posts the process of pushing code to a platform like Cloud Foundry is quite easy but it still a push can take between one and two minutes and during the most part the app has to be down. One or two minutes doesn't sound too bad for most people, but while working for EMC I have met some customers for which "mission critical" has a complete different meaning. I have seen systems where 1 second downtime could be measured in hundreds of millions of dollars.

There is lots of talk about CI/CD (Continuous Integration and Continuous Delivery) but here we are talking about accepting a minute downtime. Well, the good news is that Cloud Foundry has the tools to allow you to do a zero downtime deployment. The most common procedure is typically referred to as "Blue-Green deployment.
The trick is to have two environments (Blue and Green) and to bring them up concurrently and balance connections between them. The old and new code coexist for a short while until the deployment team has determined everything is OK.

Or they could potentially be up concurrently for a longer time to perform A/B tests. Typically you want small amount of connections hitting the new code or your A/B test environment. This is controlled from the load balancer. Cloud Foundry out of the box is able to do round-robin between all instances of the same app. So in the absence of more sophisticated load-balancers if you wanted 10% of your connections to use the new code you could spin up 1 instance with the new code for every 9 instances currently in production.

All this is made possible by distinguishing between the app name and the route to access it. For example when you do


cf push myappname

as we did in post Cloud Native Apps with Cloud Foundry Cloud Foundry will create route:


http://myappname.cfapps.io

If you have more than one domain you get a chance to specify that too. This is fine and good but you can also specify both the app name and the route it will be accessed on (and optionally the domain) like this

cf push myappname -n my-app-staging

And then it will be accessible at

http://my-app-staging.cfapps.io

Then you can make use of the "cf map-route" and "cf unmap-route" to assign different routes to the apps, such as production or staging. Take a look at the video for more details.



Comments

Post a Comment

Popular posts from this blog

Sending PowerStore alerts via SNMP

By Al
Image
In this previous article we discussed how to leverage PowerStore's powerful API to collect audit logs and send them to a Syslog server . We used Logstash to do that because of its extensive list of plugins Sometimes I come across organizations that still have a requirement to send storage array Alerts to SNMP. As in the Syslog case, ultimately most modern monitoring tools today support collecting information via REST API because that's the way the application world is going, i.e. the cloud native way ... it would be fun to see Prometheus monitoring Kubernetes via SNMP :) However there is still some requirement out there for SNMP traps, so we will explore how to do it. For simplicity we will use the same toolset that we used in the previous article. I encourage you to revisit quickly the article as we did an extensive introduction to Logstash, with practical examples as well as a description of the logs available in PowerStore. I won't cover those aspects in this article I
Read more

Electronic Nose - eNose

By Al
Image
In the previous article I provided details on VeeFarm which was one of the best projects we saw in ANZ Pied Piper 2019 edition and one of the best projects in the history of the program. The program inspired me and others to work together to showcase a great idea and the Pied Piper program itself during our presales conference. An idea I suggested to enhance VeeFarm was an electronic nose that could be used to detect the optimal ripening of the produce to advise the owner that it is the right time to pick it up the produce. This is an idea I had in the backburner for a while but never found the time to work on. Vee gave me the perfect excuse. The electronic nose, or eNose for short, is a custom PCB that hosts a range of gas sensors. For the proof of concept, I used the cheap MQ sensors. These are designed mostly for hobbyists and makers and they barely cost $1 per sensor. As one could expect, tweaking and calibrating these sensors it is even harder than the most expensive counter
Read more

Use Vagrant to deploy to AWS

By Al
Image
In the Pied Piper program we run through a Vagrant tutorial as we found it a great tool to help set up other labs. We are not going to cover Vagrant in detail in this blog as there are plenty of good examples out there. If you are interested in the exercises we did you can visit the repository: https://github.com/cermegno/vagrant-lesson However, something I felt is not sufficiently document and would make a good candidate for a post is how to use Vagrant to deploy to AWS and particularly from Windows. I found a couple of posts that provided good detail but none of them prevented me from running into Windows specific issues. If you are running it from Linux, this article will still help you as I will point out the differences anyway. Install prerequisites Firstly, as the Vagrant documentation states, "providers" other than VirtualBox require a plug in. This is how you install the AWS provider: vagrant plugin install vagrant-aws Deploying to AWS EC2 generally mea
Read more