Tech Tuesday: Why Are We Building a PaaS For Ourselves?
28 March 2017 |
Miiro Juuso | About a 3 minute read
Platform as a Service.
That’s a mouthful.
First, let me give you a bit of background.
We dedicate a portion of our time to internal projects. We see internal projects as our vehicle to improve our delivery and technology skills. We do this in a safe environment, a place where it’s OK to try new things and take risks – and sometimes, inevitably, fail.
And of course, the beauty of building internal products is our ability to bring them to our prestigious clients. We’ve created a plethora of great things to help our clients deliver better software faster.
One of our challenges in building internal products is high internal team turnover. As client demands change, the teams we allocate to internal projects change. This sometimes leads to teams facing the same problems over and over again, and consequently having to reinvent the wheel over and over again.
From a technical point of view, the above often culminates in environments and deployment. When we build a new application, how do we get it on a server? How do we deploy a new version of an existing application? What environments do we have? Can we create a new environment?
We started thinking “If we could provide a framework – or a platform – for our teams to deploy applications to, they’d never have that problem again”.
We already tick a few boxes to make this feasible;
- Most of our applications run in Docker containers already. While containers can take you to horrible places, their advantages here clearly outweigh the disadvantages.
- We tend to outsource the trouble of running databases. Generally this means we use AWS RDS and mLab.
- We use fairly uniform pipelines in Jenkins to test, build and package our applications as Docker images – and push them to a private Docker Hub registry for storage.
Cue ANDPaaS, our internal AND Digital Platform as a Service. It enables our teams to trivially build hosting environments for our applications, from testing all the way to production.
Our technology of choice to build ANDPaaS is Rancher. If you haven’t taken a look at it, I highly recommend you do. You can think of it as a management layer on top of container orchestration. In addition to providing a concept of environments, it gives us a beautiful UI for managing our software stacks.
We provide our teams with three separate ANDPaaS environments: andpaas-dev, andpaas-prd and andpaas-sandbox. The first one is for testing environments (something you would run your integration, UAT, WIP etc. environments on), the second one – obviously – production, and the third one, a sandbox environment, enabling teams to test the platform functionality in a safe space. We give everyone in the company access to dev and sandbox, and limit production access to a subset of developers.
Deploying to different environments is done in Jenkins pipelines. We’re currently in the process of building uniform modules to achieve this – something teams are able to integrate into their existing pipelines with ease.
While we expect to be fully running in ANDPaaS later this year, we’re already looking at the next pain points we can fix. Perhaps we can provide a NFR testing stack for our teams to use? How about operational application monitoring as a service?
By unifying our approach to Continuous Delivery, we minimise maintenance overhead AND make it easy for our internal teams to deliver value from day one.
Do you have similar challenges in your team, or have you perhaps found a different solution to solving them? We’d love to hear from you – please leave a comment below or reach out to me via e-mail.Read More From This Author
Senior Magento Developer
Technologists, experts in their domain, inspirational mentors and coaches.
Technologies you will be using
Leader in Product Delivery AND passionate about developing others.I'm Interested