A New Definition of Modern Apps
Serviceful and managed with GitOps
Hello everyone! Well, I said I was going to post more, and here’s another one. This time, I want to talk about the concept of modern applications and modern application development. What I am seeing is that more and more enterprises are embracing serverless (I prefer to say serviceful, I gave a talk at Kubecon on this topic), they are building real time event driven capabilities into their apps, they are managing everything with CI/CD, and they are using declarative APIs. Operationally, folks are gravitating to GitOps for continuous deployment where the declarative APIs that you use to define your applications is managed via revision control systems and any change triggers a reconciliation of your deployed application.
So Modern Apps are serviceful and managed by GitOps
Serviceful
I believe application development is going serviceful, meaning that they are full of services, on-premises or in the Cloud. At a core level, this means that the bits of an applications that are not pre-existing Cloud services are containerized, run on Kubernetes, and are managed via CI/CD. That’s the modern application approach that began when the container revolution took place. At the same time more enterprises were putting CI/CD in place with sophisticated application life cycle systems to increase speed of development.
Today, many enterprises are more familiar with this approach. CI/CD systems are in place generating containers that get stored in registries, they’re being signed for good auditing, good security hygiene, and so on. Those applications that are containerized, or services that are containerized, are deployed on Kubernetes.
The other side of serviceful is the side of the Cloud services. That’s when you do not want to re-invent the wheel and manage it and instead use a managed service from a Cloud provider. Some companies are fully Cloud-Native and only deploy apply made exclusively of services from Cloud providers but often companies will have a mix: Some microservices that are containerized and managed on Kubernetes and some services provided by a public Cloud.
Bottom line, not only is your “face full of yaml” but you are also “full of services”
It sounds a bit funny but it is the reality
GitOps
You will find different explanations about GitOps, with Weaveworks and the Flux project leading the way. The picture below is from Google. There are many different versions of this picture out there, but for my purposes here, I like this one.
What you see is source code of an application stored in a repository. When you make a push, it triggers cloud build jobs, which generate containers images that get stored in container registry. So far so good !
The interesting point is that now that your application is fully declarative, you can declare how this application should look in production through your manifest, the famous “desired state”. The kicker is that you guessed it, the deployment manifests can also be stored in your version control system. When a successful build happens, you apply those manifests in your Kubernetes cluster.
That’s the GitOps application pipeline. And we do exactly the same thing at TriggerMesh for your integration pipeline, because with our declarative APIs representing event sources, event sinks, event filters, event transformers and so on, you can represent the desired state of your integration whether it is an Event Driven Application, a Data streaming pipeline or an automation workflow.
If you head over to the TriggerMesh blog, I take this thought a little further by bringing in the concepts of Serverless (or Serviceful as I prefer) and Event-driven together.