Cloud Native – Shift right to shift left
What does shift left mean? To me, it means continuously improve and shorten your feedback loop. If you see your code creating problems to more systems and people than necessary, there’s a chance you can shift left and you should always strive towards that.
I’ve just found out that I could shift right to get a tighter feedback loop.
Sometimes limitations are a good thing
One of the best Ted Talks1 I saw in 2016 was by Tim Harford, which begins with a story about a live concert in Köln by Keith Jarrett and an unplayable piano. This concert came to be the best-selling solo album in jazz history and the best-selling piano album2. This talk taught me to work with limitations rather than letting them stop me for being successful.
When I bought my MacBook Air M1, I of course knew my toolset wasn’t fully available. On a normal day, I would use an IDE with extensions for coding, building and debugging. However, as all these tools aren’t available right now, this was now my unplayable piano.
Reading about Cloud Native IDEs in Chris Aniszczyk’s3 predictions for 2021 back in January, I didn’t realize that it was exactly what I needed to do. I was trying to get my old way of working, locally, when I needed to change where I was doing my development – to a Cloud Native IDE.
GitLab and Web IDE
I shifted left by shifting my development environment to the right; onto GitLab with its Web IDE. I use my already defined pipelines as the feedback loop thus removing the need for additional tools on my local computer. There are some drawbacks of course; it can take a while for a GitLab Runner to finish. But these are only the first steps towards going fully cloud native with my development workflow.
I know there’s support for using Gitpod4 on GitLab which is definitely a next step for me. I believe it will solve some, if not all the drawbacks. If it is anything like Google Cloud Shell5, then it would truly be a cloud agnostic solution.