Modern software applications are underpinned by a big and growing web of APIs, microservices, and cloud services that need to be extremely readily available, fault tolerant, and protect. The underlying networking innovation must support all of these requirements, naturally, however likewise explosive growth.Unfortunately, the previous generation of innovations are too pricey, breakable, and badly incorporated to sufficiently resolve this difficulty. Integrated with non-optimal organizational practices, regulatory compliance requirements, and the need to provide software quicker, a new generation of technology is needed to deal with these API, networking, and security challenges.CAKES is an open-source application networking stack constructed to integrate and better fix these obstacles. This stack is planned to be combined with contemporary practices like GitOps, declarative configuration, and platform engineering. CAKES is constructed on the following open-source innovations: C-CNI(container network interface)/ Cilium, Calico A-Ambient Mesh/ Istio K-Kubernetes E-Envoy/ API gateway S-SPIFFE/ SPIRE In this short article, we explore why we require CAKES and how these technologies fit together in a modern-day cloud environment, with a concentrate on accelerating shipment, reducing expenses, and improving compliance.Why CAKES?Existing technology and organization structures
with the surge in APIs, the need for iteration, and an increased speed of shipment. Best-of-breed technologies that integrate well with each other, that are based on modern-day cloud principles, which have been proven at
scale are better geared up to deal with the difficulties we see.Conway’s law strikes once again A significant obstacle in business today is staying up to date with the networking needs of contemporary architectures while also keeping existing innovation financial investments running efficiently. Large companies have numerous IT teams accountable for these needs, but sometimes, the details sharing and interaction in between these groups is less than suitable. Those accountable for connection, security, and compliance usually live across networking operations, details security, platform/cloud facilities, and/or API management. These groups typically make decisions in silos, which causes duplication and integration friction with other parts of the organization. Often,”integration “between these teams is through ticketing systems. For instance, a networking operations team normally oversees technology for connectivity, DNS, subnets, micro-segmentation, load balancing, firewall software appliances, monitoring/alerting, and more. An information security team is normally involved in policy for compliance and audit, managing web app firewalls (WAF), penetration testing, container scanning, deep package evaluation, and so on. An API management team takes care of onboarding, protecting, cataloging, and publishing APIs.If each of these teams separately selects the innovation for their silo, then combination and automation will be slow, brittle, and costly. Modifications to policy, routing, and security will reveal fractures in compliance
. Groups might end up being baffled about which innovation to utilize, as undoubtedly there will be overlap. Preparations for changes in support of app designer efficiency will get longer and longer. In short, Conway’s law, which states that an organizational system frequently wind up like the interaction structure of that organization, raises its awful head.< img alt="cakes 01"width ="1200"height="716" src= "https://images.idgesg.net/images/article/2024/04/cakes-01-100963038-large.jpg?auto=webp&quality=85,70"/ > Solo.io Figure 1.
Innovation silos lead to fragmented technology options, expensive and breakable integrations, and overlap Sub-optimal organizational practices Conway’s law isn’t the only problem here. Organizational practices in this location can be sub-optimal. Executions on a use-case-by-use-case basis lead to lots of separated”network islands”within a company because that’s how things”have always been done.”For example, a new industry spins up, which will offer services to other parts of business and consume services from other parts. The modus operandi is to develop a brand-new VPC(virtual personal cloud), set up new F5 load balancers, brand-new Palo Alto firewall softwares, produce a brand-new team to configure and handle it, and so on. Doing this use case by use case triggers an expansion of these network islands, which are tough to
integrate and manage.As time goes on, each team solves difficulties in their environments independently. Gradually, these network islands start to move far from each other. For instance, we
at Solo.io have actually worked with big financial institutions where it prevails to discover dozens if not hundreds of these drifting network islands. Organizational security and compliance requirements become very hard to keep constant and auditable in an environment like that. Solo.io Figure 2. Existing practices result in pricey duplication and complexity. Out-of-date networking presumptions and controls Finally, the presumptions we have actually made about perimeter network security and the controls we utilize to enforce security policy and network policy are no longer legitimate. We’ve generally appointed a lot of trust to the network border and “where”services are deployed within network islands or network segments. The”perimeter”degrades as we punch more holes in the firewall program, utilize more cloud services, and release more APIs and microservices on facilities and in public clouds(or in multiple public clouds as demanded by guidelines). When a harmful star makes it past the boundary, they have lateral access to other systems and can get access to
delicate information. Security and compliance policies are usually based on IP addresses and network sections, which are ephemeral and can be reassigned. With fast modifications in the infrastructure,”policy bit rot” takes place rapidly and unexpectedly. Policy bit rot takes place when we mean to implement a policy, but because of a modification in complicated facilities and IP-based networking guidelines, the policy becomes skewed or void. Let’s take an easy example of service An operating on VM 1 with IP address 10.0.1.1 and service B working on VM 2 with IP address 10.0.1.2. We can write a policy that states “service A need to be able to speak to service B”and execute that as firewall rules permitting 10.0.1.1 to talk to 10.0.1.2. < img alt="cakes 03 "width =" 1200 "height="390"src="https://images.idgesg.net/images/article/2024/04/cakes-03-100963040-large.jpg?auto=webp&quality=85,70 "/ > Solo.io Figure 3. Service A calling Service B on 2 various VMs with IP-based policy. 2 easy things might occur here to rot our policy. Initially, a brand-new Service C might be deployed to VM 2. The result, which may not
be intended, is that now service A can call service C. Second, VM 2 could become unhealthy and recycled with a brand-new IP address. The old IP address might be re-assigned to a VM 3 with Service D. Now service A can call service D however possibly not service B. Solo.io Figure 4. Policy bit rot can occur rapidly and go unnoticed when depending on ephemeral networking controls. The previous example is for an extremely simple usage case, however if you extend this to numerous VMs with hundreds if not thousands of complicated firewall program rules, you can see how modifications to environments like this can get manipulated. When policy bit rot occurs, it’s really hard to understand what the current policy is unless something breaks. But just because traffic
isn’t breaking right now does not suggest that the policy posture hasn’t end up being vulnerable.Conway’s law, complex infrastructure, and outdated networking assumptions produce an expensive quagmire that slows the speed of shipment. Making changes in these environments causes unforeseeable security and policy effects, makes auditing tough, and undermines modern-day cloud practices and automation. For these reasons, we require a contemporary, holistic technique to application networking. A better method to application networking Technology alone will not fix a few of the organizational difficulties gone over above. More recently, the practices that have actually formed around platform engineering appear to provide us a course forward. Organizations that purchase platform engineering teams to automate and abstract away the complexity around networking, security
, and compliance enable their application groups to go faster.Platform engineering groups handle the heavy lifting around integration and focusing on the ideal user experience for the organization’s designers. By centralizing typical practices, taking a holistic view of a company’s networking, and using workflows based on GitOps to drive delivery, a platform engineering team can get the benefits of finest practices, reuse, and economy of scale. This enhances dexterity, decreases costs,
and allows app teams to focus on providing new worth to business. Solo.io Figure 5. A platform engineering group abstracts away infrastructure intricacy and presents a designer experience to application developer groups through an internal designer portal.
For a platform engineering group to be successful,
we need to give them tools that are better geared up to live in this modern-day, cloud-native world. When thinking of networking, security, and compliance, we ought to be believing in terms of roles, responsibilities, and policy that can be mapped straight to the organization.We ought to avoid depending on”where “things are released, what IP addresses are being used, and what micro-segmentation or firewall guidelines exist.
We ought to have the ability to quickly look at our” intended” posture and easily compare it to existing implementation or policy. This will make auditing easier and compliance much easier to ensure. How do we achieve it? We require 3 easy but effective foundational principles in our tools: Declarative configuration Workload identity Basic integration points Declarative setup Intent and current state are often muddied by complexities of a company’s infrastructure. Attempting to learn thousands of lines of firewall rules based on IP addresses and network segmentation and understand intent can be almost impossible. Declarative setup formats help fix this.Instead of thousands of vital actions to achieve a preferred posture, declarative configuration enables us to extremely plainly state what the intent or the end state of the system must be. We can take a look at the live state of a system and
compare it with its desired state a lot more easily with declarative configuration than attempting to reverse engineer through complicated steps and rules. If the facilities changes we can”recompile”the declarative
policy to this brand-new target, which enables dexterity. Solo.io Figure 6. Declare what, not how. Composing network policy as declarative setup is not enough, nevertheless. We’ve seen big companies build good declarative configuration models, but the intricacy of their facilities still causes complicated guidelines
and brittle automation. Declarative configuration should be composed in terms of strong workload identity that is connected to services mapped to company structure. This work identity is independent of the infrastructure, IP addresses, or micro-segmentation. Work identity helps in reducing policy bit rot, reduces configuration drift, and makes it simpler to reason about the intended state of the system and the real state.Workload identity Previous approaches of building policy based upon
and permission policies with declarative configuration that are much easier to investigate and that map plainly to compliance requirements. A top-level compliance requirement such as”test and developer environments can not interact with production environments or data”becomes simpler to implement. With work identity, we know which workloads come from which environments because it’s encoded in their work identity.Most companies currently have existing financial investments in identity and gain access to management systems, so the last piece of the puzzle here is the requirement for basic combination points.Standard integration points A big discomfort point in existing networking and security applications is the pricey integrations between systems that were not intended to work well together or that expose exclusive
integration points
. Some of these combinations are heavily UI-based, which are tough to automate. Any system built on declarative configuration and strong workload identity will likewise require to integrate with other layers in the stack or supporting technology. Source
