<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=70416&amp;fmt=gif">

Sorry! Your browser is not supported on this site and it might be acting a bit wonky. Please use Firefox, Chrome or Edge instead

From startup to Google scale

Written by:
Sakari Hoisko

Continuous Deployment and Docker are the hot topics these days. Join the heat, read more and learn to fly with us!

Continuous Delivery (CD), Continuous Deployment and Docker are the hot topics these days. In principle CD is part of a Devops pipeline that extends Continuous Integration (CI) and delivers production software to production environment with gates. Continuous Deployment deploy software from CD to production without downtime.

When this delivery happens continuously, the production software and environments needs to be built up so that there is no continuous downtime (=continuous deployment). We could avoid downtime with load balancers and rolling updates. What does it require? We need an execution platform where load balancers and rolling update features are built in or we have to build it by ourselves… But let’s not go there yet because we are a startup and we don’t need it YET, but we should aim there.

We have just started learning to fly. So how we can learn to fly? Let’s create software the way where it is stateless and the business platform supports multiple instances of software with different versions. Yes, it should be stateless and the database should support multiple different versions of software up & running at same time. Why? Because when we learn to fly we don’t want to fall down. It will generate pain if we don’t make the software basics in a correct way – we fly high with it and we try to get higher.

When platform of the software is done in a correct way we can pack it to a docker image and deploy docker containers by using that image. Because we are a startup it is enough to us that we only have one instance up & running in live. We also don’t have that much customers so a small downtime is okay if we are able to choose the exact time of it. We also like systems type of services (old school) so much that we use it in production to run and monitor our product. Shortly continuous delivery is enough to us in this situation but we aim/prepare to continuous deployment.

We deploy our web service container from system service by using docker layer. Then our product is saved in a docker hub behind of private account. Actually all versions of our product is there and we are able to start any version from our product at any time. Rollback is supported and it takes only same downtime than activation in update. Our CD pipeline includes gates where we can control what versions and when the production itself will be updated. Update doesn’t do anything else than just copies (docker pull) the software (docker image) to production. After activation gate we have some downtime which is the only downtime what software (docker container) restarting needs. So basically, now we have full CD pipeline and software which can be added behind the load balancer so we are able to get rolling update and dynamically scale our product (=continuous deployment). It gives your startup horizontal scalability, continuous deployment and automatically fall back in fail over. Just take it to use to existing software when you need. Nice!

So let’s start from a scratch and expand it to google scale with docker later on. Virtual machines are so beginning of 21st century and by the way, Amazon includes Elastic Load Balancer, Relational Database Service and many more features so we as a startup can focus to our business product without creating wheel again. When do we start? Could we do it by using docker? Why the platform could not be in cloud?

P.S. Whole Amazon works on top of containers so if you are doing bigger systems and you need more mature platform, then cloud and docker is not an option for you ... or should you still reconsider?

Let’s fly together!

Do you want to learn more about Docker? Contact us and let's talk!