Photo by Steve Johnson on Unsplash

Opinionated Backend Cloud Service Delivery

In this post I am expanding on an original question I asked recently where I am looking for an opinionated build/deploy solution. I will provide some context on the software delivery model and tools used today, challenges with it and issues I am seeking to answer.

I live in the backend Java/Kubernetes ecosystem for Cloud/SaaS services so all examples are in context of that world. Tools/frameworks listed are examples only.



“convention over configuration”

as I first learnt Maven (also see Stack Overflow). There is essentially a “golden path” to using the tool/framework and you are strongly encouraged to follow it. You may diverge but then you are on your own.

Why is it important? It establishes a convention which does not mean it is the “right” or only way but it shows the best practices that are agreeable to most. It also establishes familiarity and shorthand language that practitioners will easily understand even in new situations. For example knowing Maven/Gradle I can goto any project in any company using it and I know how code is organized and you know what I mean if refer to src/test/resources.

Software Delivery Journey

  1. Write Code — understand the business problem and solve it
  2. Write Tests — to ensure functional/non-functional success. These are various types of tests like unit, component, integration, end-to-end, performance etc as per the test pyramid
  3. Deploy — appropriately package all the code and dependencies and make it available in various environments (dev/stage/production or other similar names you may use)
  4. Observe/Support Environment(s) — monitor/alert/pager duty/debug

These are not necessarily sequential tasks, there is always overlap and let us consider the following simple overlap:

The above conceptual model translates in the following general steps:

code-test-deploy-observe overlap
code-test-deploy-observe overlap

Step 1 — Build

For example: Using Gradle with Spring Framework and JUnit tests, doing a code review and producing a Docker image.

In this step Spring Boot provides an excellent opinionated solution. All parts are integrated producing the docker image. One part missing though is the code-review process so depending on your SCM (gitlab, github etc) you need to setup your own merge and gating process.

Step 2 — Verify

For example: deploying a new namespace with new binary along with other dependencies, configuring secrets and running contract tests, e2e tests, manual tests, performance test etc and determine the outcomes.

In this step there is no opinionated solution that I am aware of. You must stitch together your own solution, for example using a CI tool (like Jenkins) along with others like Selenium, Cucumber, JMeter, Sonar, Vault, Jira, Helm, Hoverfly/Wiremock, bash/python glue scripts etc to come up with something that works.

Step 3 — Release

For example: using canary/blue-green or other deployment model to release, observe outcomes and then proceed or rollback.

In this step again you must stitch together your own solution, for example using a CD tool like Spinnaker or even Jenkins along with others like Selenium, WaveFront, Prometheus, Helm, Vault, Jira, bash/python glue scripts, Fluentd to forward logs etc.

Future State

Yes, there will be a trade-off. Using such a system will require following constraints of such a stack but in return a standard operating model can be established across multiple microservices and teams.

An opinionated framework like Spring Boot does not need to end once the jar is created, instead it needs to follow it through the rest of the software delivery journey!

If you have ideas on how to achieve this please share your thoughts and I will be happy to collaborate on open-source projects as well.

Originally published at

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store