The 21st century is all about cloud native applications, but designing containerized applications or microservices is only the tip of the iceberg. What we do in design needs to push the boundaries even further.

Software is not just about providing a service to customers, it is also meant to be highly reliable and available. This is only possible through severely restricting development processes, as well as focusing on continuous integration, delivery, and production access.

Of course, as a developer, you don’t want to have too many restrictions while creating your software, writing your code, or defining your DockerFile or equivalent. But you have to recognize that the more constraints you impose on yourself and your teams, the more stable the output will be.

Then when these constraints become a habit, you won’t even notice them anymore. All the while, you will have learned a lot more about security operations than you expected, improved your onboarding processes, and made the “go-to-production” decision far simpler.

Kubernetes is not magic. I was disappointed when I started using it and realized that a part of my life had been sucked into yaml files. That being said, once you dig a little deeper, you realize that it can actually be a powerful tool for various kinds of production environments.

In prior times when we developed an application or a product, we usually followed these steps (more or less in this order):

  1. Find and define your market needs.
  2. Define your software architecture, databases, models, etc.
  3. Coding.
  4. Add some testing, CI/CD processes.
  5. Build your production environment.
  6. Go to production.

This used to be fine; at least, when you have a good System Administrator taking care of the security of your precious servers or instances. If you were lucky, as a developer, you actually would hate them — because they would always criticize the way you did things that “you were not supposed to do”.

Sponsor Note

sponsor logoKubeCon + CloudNativeCon conferences gather adopters and technologists to further the education and advancement of cloud native computing. The vendor-neutral events feature domain experts and key maintainers behind popular projects like Kubernetes, Prometheus, gRPC, Envoy, OpenTracing and more.

Depending on your generation, or the companies you have been a part of, you may have never experienced this.

But now, what if we did things a little differently, to ensure that what we offer to our customers is indeed highly reliable, available, and built with best practices in mind?

Your Production Environment Is Key

In the end, we know that any part of our workload can crash — that is, any part but our production environment. Customers never have to be understanding while using a service; they are paying for it after all. They are our first resellers and should never be let down. Taking care of them is our main responsibility.

Your production system and your customers are interdependent.

Our goal is always to avoid downtime and provide the best service possible. So, instead of putting the code first, why not change your way of designing things and start by defining our production architecture first?

The choice of your database or models can wait, as well as your front-end application, and so on.

So let’s update our product creation process:

  1. Find and define your market needs.
  2. Define your production architecture: types of third parties you will need, deployment strategy (CI/CD, tools, etc.), container technology.
  3. For each item listed above, define guidelines corresponding to a restrictive approach for maximum security. For instance:
  • Define templates and guidelines for your Dockerfiles
  • List and define the configuration of webhooks to check file modifications (linter, templating, format validation, etc.).
  • Define the user roles and access to each item and environment.
  1. Implement the constraints you defined.
  2. Now feel free to make the last architecture decision (databases or other third parties).
  3. Coding might feel a bit restrictive in those conditions, but it’s for the best.
  4. Go to production. Everything is ready, right?

#cloud native #development #kubernetes #contributed #sponsored

How Design Impacts the Security of Cloud Native Applications – The New Stack
1.10 GEEK