![]() ![]() The alternative architecture, multi-tenanted, completely disallows the monorepo approach and you must have separate repos for each of the layers. The app per cluster model allows you to use a monorepo that can completely rebuild your app from the ground up with minimal human interaction. OPA is an amazing tool when decentralising responsibility for the lower layers of an app while maintaining central control and I can't recommend it highly enough. verifying that a dev team isn't running a bitcoin mining operation, or publishing pro-trump/fascist/racist propaganda to our public-facing websites). Solution 2 would require the implementation of 'initial trust' base infra with something like Open Policy Agent (OPA) rules to ensure that dev teams are complying with organisational governance requirements (e.g. Solution 1 would require separate repos for infra, platform, and app, and this usually results in a need to synchronise the backlogs of the respective teams, which quickly becomes a logistical nightmare as the number of teams increases. One of the biggest benefits here is that a dev team can make the changes they need to make (to the infra and platform) and issue pull-requests for the application teams to manage, without having to coordinate the schedules of the teams and thus reducing impedance.īoth solutions have their problems and complexities, but both are manageable given good engineering leadership and tool support. This model is by far the most common and currently represents the best solution for highly regulated industries. The infra and platform teams can provide access to their git repos, and the dev teams can fork them into git submodules within their own mono-repos. This works well when a team has little or no DevOps capability, but it is far from being the best solution as it creates a dependency from the dev team to the infra and platform teams which usually causes impedance and added complexity. The infra and platform teams can provision clusters on behalf of a dev team and provide the pipelines needed to deploy applications to it. We have 2 main models to provide access to the output of the centralised infra and platform teams: In modern orgs we work with a cross-functional team that has some skills in each of the areas we need, including DevOps, and each team member is also a member of a group that is focused on their speciality where they receive groupwide instruction. Instead, we have centralised teams for infra and platform, and they distribute their output to the development teams and we typically work with the cluster-per-app model. ![]() Distributing this effort to each team would be a governance and compliance nightmare and hiring that many people with the right skills would be impossible. In these organisations, we have hundreds (even thousands) of development teams and it is impractical and inefficient to expect each team to develop its own infrastructure and platform layers as well as their application. My experience comes mainly from large banks. ![]() Another factor is which team owns the various layers of the architecture and how they will distribute their output. When making your decision you need to factor in whether you are working with an app per cluster, as is becoming more common in modern K8S systems, or a shared cluster. Simply maintaining a single version for all your applications, infra, and platform will have the same effect. In this answer, I'll mainly address the benefits, techniques, and drawbacks of monorepos, though you don't have to go deep into monorepo culture for this to apply. I think the question you're asking relates to the concept of 'monorepo', where all the code needed to build and deploy your application is contained in a single repo and versioned together. Application is the business logic and software that runs your business, confusingly this is also often provisioned with kubectl or helm, and possibly packer if you're into the wonderful immutability model.stuff you typically provision with Packer, kubectl, or helm (and, this is the first blurring, because EKS, AKS, GKE, are often provisioned with terraform too) Platform is Kubernetes, OpenShift, IIS, etc.Infra: machines and VMs, security and resource groups, auto-scaling groups and elastic load-balancers - stuff you typically provision with Terraform.These 3 layers are blurred at the boundaries and there is a continual debate about their delineations, but if you're not familiar with this model, roughly: In this admittedly long answer, I'll talk about the 3 layers of an organisation's IT operations - infrastructure, platform, and application. Tl dr - read the final section, it's the most important. The correct answer, like almost everything in IT, is, "it depends." It depends on the way you work, the type of company you are working for, your requirements, your non-functional requirements, and possibly a lot of other factors. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |