Finally! It's taken four months but my first microservice is now online. Although to be fair in those 4 months I went on two ski holidays, and had a couple of family events so for a spare time after work project it is pretty good. What I have is a multi tenant, SAAS security and login service, complete with administration ui. This is all deployed using a continuous deployment (CD) pipeline. This is a great platform to start testing out the ideas I put forward in this article. I will use the service in a lot of other projects and as I add new functionality and continually improve it I will start to experience the type of decision making that is required when maintaining a production service. I am looking forward to seeing if my major/minor versioning ideas pan out.

Codefresh.io

I am testing out a whole host of ideas and concepts here but my major learning achievement was something I didn't expect. I took the development of a CD pipeline for granted but there was more to it then I thought and during the process I seem to have fallen in love with Codefresh.io because it became a major tool for achieving my CD ambitions! This is going to annoy the people I work with somewhat because I have spent years trying to get them to let me use Jenkins for automating development tasks. Six months ago they finally let me have access to a centrally managed Jenkins service. I have created a few pipelines using Jenkins and slapped build status icons in various points on our confluence documentation site; but now I am going to go back to the powers that be and tell them I want something else.

Why?

Codefresh wins in comparison with Jenkins because of simplicity. In Jenkins I spent ages fiddling with pipeline setup and finally got deployments working exactly how I want. The problem now is I am faced with the task of documenting this and training other teams in best practice. I already have a complicated set of instructions put together in confluence. It's important developers learn how to use the complicated Jenkins configuration in order to debug issues in the builds and make sure the correct notification emails are sent.

My experience with codefresh was much simpler. It's entirely based on docker containers and the build is described in a simple .yml file. This file lives in the git repository so is version controlled hence very maintainable. Also I have abstracted away all the complex logic of various steps into docker images further simplifying the entire process. This removes the need for training developers in Jenkins and with good practice in making a self documenting .yml file I believe it is going to be easier for developers to work with.

Codefresh is also simpler because there is no infrastructure for us to maintain. This is a great benefit as in Jenkins the builds stopped working a month ago due to the slave machine we use not working with the master. I know how to fix it but I don't have admin permission on the main server to reconnect them. It's taking me a while to persuade the right people with the right access to get it fixed. With Codefresh these headaches will be banished because everything is maintained for me.

Building up Microservice compatible infrastructure

So four months for one microservice? That doesn't seem right! These things are supposed to be small agile things you can throw together quickly, do I judge the four month build time for the first MVP a failure?

Well I don't think this represents a failure, although I could be wrong. One of the reasons it took so long was due to my after skiing coding sessions giving way to the lure of Apries-ski! The other reasons all this took so long are:

• I was learning a lot - falling in love with Codefresh and learning it by falling into it's pitfalls
• Spending a long time creating an infrastructure. (e.g. secure password storage methods etc.)
• I made robust features and included multiple levels of automatic testing
• I was doing this solo which meant I had to refactor my way out of a few non-optimum choices, it would be great if I had other developers to bounce ideas off.
• Repeated heavy refactoring to streamline the process

In fact I have a second microservice I threw together in about 4 hours by copying and pasting much of the deployment and python code from the first. I then evaluated all the stuff I was copying and pasting and embedded that into docker images and python libraries so next time it will be quicker still.

Right now I think I am at the beginning of putting together a microservice production line. I have the feeling that as I build more and more I will continually refine the process which will cut the development overhead considerably.

So what next?

Next is the exciting bit. I have to put together at least one MVP for a SAAS that uses this mircoservice for user authentication, this will inevitably lead to adding more features to this microservice. As the needs and requirements of the MVP's I put together I will find out if this whole host of development strategies can truly build a robust and rapidly changing platform. I am due to make many mistakes but I think I will enjoy the process!