For many years, the North Pole's gift factory had been running on a powerful hyperscale cloud far beyond the northern skies, known as AuroraSphere - a cloud system the elves adored at first. It came with seamless wishlist ingestion, flight route optimization, reindeer-telemetry, all wrapped in functions like "Magical scaling" and "GiftOps Manager", convincing Santa that this was indeed the future of Christmas Operations (chrisOps). 

But year by year, the systems became more.... tangled. 

Every time another Christmas function was added, the industrious elves discovered another convenient AuroraSphere component that "solved it in 5 minutes". Unfortunately, all those 5-minutes solutions had now merged into a massive christmas-snowball of dependencies. The reindeer tracking system was so deeply tied to AuroraSphere's proprietary APIs that even just opening the documentation felt like trying to keep snowflakes still in a snowstorm: everything moved. 

The elves started asking questions - which no one really wanted to answer: 

• What happens if we try to move the telemetry out of AuroraSphere? 
• Why are the wish-lists placed in three different regions and not replicated? 
• Who activated GlowMode™ without a change request?

And when one elf asked: "Boss ...where do our data actually live?" ...a sudden quiet fell over the forge. Even the bells on Santas coat stopped ringing.

One early December morning, Santa received a message from AuroraSphere that hit like a falling icicle: 

"Your account is under review for potential temporary suspension due to updated policy criterias" 

Every elf in the room stopped. The reindeers flattened their ears. 

No one had imagined that the Christmas operations - the most stable workflow in the world - could be affected by anything else than capacity and technicalities - never something as distant as policy changes. 

And now it turned out that world politics had found its way into Christmas logistics. AuroraSphere could - entirely within their rights - limit access to services if the user was located in a region that could be perceived as politically controversial. And the North Pole’s climate impact, combined with a not entirely politically correct "Naughty or Nice" regulation had triggered the algorithms. And suddenly, wishlists, flight path analytics, and the entire Christmas gift delivery chain was tied to circumstances far outside Santas control. 

When the elves checked the AuroraSphere console, a bad situation turned even more confusing. The wishlists were spread between "Frost-Core-1", "CandyCane-East" and "Gingerbread-West-2". No one was quite sure who had put them there - or when - but they all agreed that this wasn’t very North-Pole-aligned. It became clear to everyone that data streams they had taken for granted, now was something they had to understand - and control. Blind trust was no longer a viable architecture.

Among the elves, there was one who had actually paid attention and cared about where stuff was located. Not where in the forge, but where in the world. It was Eira Oversight, the sovereignty elf. She had for months been mumbling about domains, data flow, and "legal snowdrifts in cross-pole transfers". The others had nodded, smiled politely and rolled their eyes, but now she was the center of the room with a distinct "I told you so" expression. 

She unrolled an old parchment and pointed to three red circles: 

• Wish-lists
• Reindeer-telemetry 
• Christmas Eve flight plans

All of them pointed to AuroraSphere regions far from the North Pole. 

"These" she said quietly, "are not just files. They are Christmas. And we no longer control it" 

The forge grew even more silent with the realization. No list of legal frameworks was needed (and would also be difficult since the Legal Elf had turned in sick as soon as he understood what was going on). Everyone understood what was at stake. 

Even Rudolf raised a concern: "What if someone turns off GlowMode™ mid-flight?" No one laughed. It was a deeply relevant question.

Santa called an emergency meeting 

"We need a platform where the doors don't’ close without warning. A sky we can trust." 

The elves immediately formed a working group with subcommittees (and because this happens in a magical place they actually got something done). By nightfall they had drafted their first set of criterias - which they wrote down on a brand new parchment with their silver pens: 

1. Data must stay within a jurisdiction trusted by the North Pole 
2. No functions should be irreplaceable without a viable migration possibility 
3. Everything must be portable - no vendor BindingCharms™ 
4. Documentation must not resemble blizzard 
5. APIs should be open, not locked behind enchanted gates (not even pearly ones) 
6. Logging and trace data must be fully visible and exportable 
7. Region placement must be deliberate, not accidental 
8. Sensitive wishlists must remain north of the polar circle 
9. Critical holiday systems must withstand global turbulence 
10. The platform must be Elf Architected™.

The elves evaluated: 

• European clouds built on familiar legal systems 
• Nordic providers offering local data residency 
• Open-source platforms where magic wasn't hidden behind proprietary walls 
• Hybrid design that allowed reindeer telemetry to stay fast and the wish-lists sovereign.

For the first time since the warning from AuroraSphere, the workshop exhaled. (And the Legal Elf, suddenly feeling much better, returned to work)

It took weeks, but eventually, the North Pole found its way onwards. 

Route- and flight optimization was moved to a European cloud with predictable latency. Wish-lists were placed under a Nordic legal canopy, where no external legal storms could threaten the accessibility. Reindeer telemetry got its own hybrid setup - fast, controlled and resilient. And most importantly: The elves did a test of the exit-strategy - and it worked. The elves celebrated with spiced cocoa (as they are not allowed to drink mulled wine in December). 

Finally, Santa gathered the entire workshop again, smiling, much calmer this time: 

"We used to think that a cloud was a cloud. But now we know better. Christmas needs a sky we can trust, not only when everything is calm, but also when the winds turn." 

And as the reindeer did the final test-flights and the elves wrapped the last gifts, they all agreed on one thing: 

This Christmas wouldn't just be delivered. 

It would be delivered with control, sovereignty, under a sky that truly belonged to everyone.

We often meet companies that have come a long way on the development side, but still struggle to keep the platform stable and secure. The result is technical debt, high operating costs and frustrated developers, a pattern we see across industries. In a world where development speed and flexibility are critical, cloud native and Kubernetes have become industry standards. 

Nevertheless, many companies still focus mainly on development, while the platform is downplayed. This leads to technical debt, unstable operations and developers spending time on infrastructure instead of product development. 

Platform Engineering changes this by providing robust, self-service platforms that give developers freedom while safeguarding operations and security. And through open source and CNCF projects, companies can build scalable, secure and flexible solutions without locking themselves into proprietary technologies.

DevOps was long seen as the solution to infrastructure challenges, but in practice it often gave developers more responsibility for operations. We still see developers spending time manually configuring Kubernetes manifests, time that could have been spent on product development. 

Platform Engineering is about building a layer between developers and infrastructure. A good platform provides self-service solutions for CI/CD, observability, security and scaling without developers having to understand all the technical details behind it.

The Cloud Native Computing Foundation (CNCF) is behind some of the most important projects in modern infrastructure. Kubernetes is at the core of this ecosystem, but tools such as Prometheus (monitoring), Argo CD (GitOps), Linkerd (service mesh) and OpenTelemetry (observability) also play key roles. 

Building on open source and a strong community gives companies access to proven solutions, and reduces the risk of vendor lock-in. At Redpill Linpro, we work closely with customers adopting CNCF projects to build robust platforms and we see how this brings both developer satisfaction and operational predictability.

Every company should have a platform strategy. Poorly configured systems lead to instability, high operating costs and frustration among developers. We have seen how companies that invest in a solid platform experience fewer production problems and more satisfied developers. 

A good platform takes into account application scaling, traffic management and high availability.

Many companies still build solutions where developers have to handle deployment, logging, monitoring and security on their own. The result is often a patchwork of technologies that require heavy maintenance. 

With a properly set up platform, developers get a better working day: faster rollouts, fewer errors and more time for product development.

At a time when cybersecurity and digital sovereignty are more important than ever, platform choice plays a critical role. Open source provides transparency and trust, while giving companies and governments control over their own data and infrastructure. Where data is stored, how applications are secured, and which actors have access to critical infrastructure are no longer just technical questions, but increasingly strategic decisions. 

By using open source, companies can reduce the risk of supplier dependence in unstable geopolitical situations. This gives greater predictability and security, and makes it easier to adapt solutions.

1. Build a developer-friendly platform: Give developers tools that remove complexity without limiting them. 
2. Automate everything: CI/CD, infrastructure as code and GitOps should be standard. 
3. Use open source: CNCF projects and other open solutions provide flexibility and security. 
4. Think long term: A good platform must be continuously improved and adapted.

Platform Engineering is a prerequisite for succeeding with modern cloud architecture. Companies that prioritise platform as highly as development build more stable, scalable and secure solutions. 

At Redpill Linpro, we help organisations navigate the CNCF landscape and build platforms that last. Want to discuss what a modern platform could look like in your organisation? Get in touch, we’re happy to share our experiences.

It's time to put platform first.

In today’s cloud-driven era, selecting the right Azure compute service is a strategic decision. Azure offers a range of options, from Virtual Machines to serverless architectures, catering to diverse needs. Whether you are migrating legacy systems or building modern applications, making the right choice optimizes costs, enhances performance, and ensures scalability. 

Start with the big question: Are you migrating an existing application or building something new?

• Need full control? Opt for Virtual Machines (VMs) to create custom environments. 
• For cloud-native workloads: 
  •   Utilize Azure App Service for managed hosting of microservices.
  •   Explore Azure Functions or Logic Apps for efficient serverless operations for event-driven tasks. 
  •   If you have containerized apps: 
  •   Simple workloads can benefit from Azure Container Instances. 
  •   Orchestrate complex, multi-container deployments with Azure Kubernetes Service (AKS).

• Lift and Shift: 
  • Containerized applications can leverage Container Instances or AKS. 
• Non-containerized applications: 
  • Commercial off-the-shelf (COTS) apps can opt for VMs. 
  • Custom apps can benefit from App Service for streamlined management. 
• Cloud-Optimized: 
  • For high-performance computing (HPC) workloads, consider Azure Batch. 
  • Combine App Service, Functions, and Logic Apps for microservices or event-driven tasks.

• Control vs. Simplicity: Choose VMs for flexibility or Platform as a Service (PaaS) for streamlined management. 
• Cost: Azure Functions offer cost-effective solutions for sporadic usage, while VMs are suitable for steady workloads. 
• Scalability: AKS and App Service dynamically scale to meet varying demands effortlessly.

The right compute service aligns technology with business goals. Azure empowers you to build resilient, scalable solutions by assessing control needs, and scalability. 

For more info read: https://lnkd.in/gGkstdp6

In November 2023, Broadcom's acquisition of VMware, a market leader in cloud computing and server virtualization, marked a significant shift in the technology landscape. The acquisition has brought about a range of sweeping changes that affect VMware's products, partners, and businesses heavily reliant on VMware for their IT operations. Although the acquisition was anticipated, many companies and industry players were unprepared for the consequences. This has created Challenges and uncertainties.

One of the most immediate concerns following the acquisition has been the sharp increase in costs associated with VMware products. Companies now have to consider whether to continue with VMware, adopt a hybrid approach, or migrate to an entirely new platform. Each of these options carries its own financial implications, and many businesses, especially smaller ones, have been caught off guard by the sudden rise in costs.

Unfortunate for loyal customers, but liberties a company with around 50% of the global market share can easily take to boost its bottom line.What role does VMware play in your organization? Will you be affected by the discontinuation or merging of products? How will the changing prices impact your budget?

These are some of the questions you need to ask when considering your path forward.

Fortunately, there are also good alternatives.

For over 20 years, Redpill Linpro has delivered strong OpenSource alternatives to VMware, such as from our own Norwegian cloud: Redpill Linpro Nordic Cloud.

Cost Savings: OpenStack can provide significant cost savings compared to proprietary virtualization solutions like VMware, especially for large-scale deployments. The potential for cost optimization through the use of commodity hardware, open-source software, and a managed service model is considerable.

Open Source and Vendor Neutrality: OpenStack is an open-source platform, which reduces the risk of vendor lock-in and provides greater flexibility and control over infrastructure. This can be especially attractive for businesses concerned about the potential impact of Broadcom's acquisition on VMware's product roadmap and pricing. 

Scalability and Flexibility: OpenStack is designed for scalability, allowing businesses to start small and scale their infrastructure as needed. It’s very easy to seamlessly scale resources such as computing, storage, and networking, without being limited by proprietary hardware or software constraints.

Customization and Integration: OpenStack's modular architecture and open APIs allow customers to tailor the platform to their specific needs and integrate it with existing tools and systems. This can be especially valuable for businesses with unique requirements or legacy systems that need to be integrated.

Nordic Expertise and Local Support: Redpill Linpro has a strong understanding of the Nordic market, a local data center presence, and the ability to provide support and services from the geographical area. This can be a significant advantage over global vendors who may lack regional expertise and proximity to customers.

Key Arguments:

• A successful migration from VMware to OpenStack typically results in an average TCO reduction of 40%.
• Redpill Linpro's pricing model is competitive due to zero licensing costs.
• In most cases, lift-and-shift is possible during migration between VMware and OpenStack, making the migration process simple.

Broadcom's acquisition of VMware has created waves in the IT industry, and it is crucial for companies to conduct a thorough review of their strategies and agreements. While such changes are often inconvenient, they also present an opportunity to explore new solutions.
With Norway's leading OpenSource environment, we at Redpill Linpro are very open to having conversations with companies looking to explore alternative options to VMware.

1. Forstå dine behov og mål

Før du begynner migreringsprosessen, er det viktig å ha klare mål og en forståelse av hva du ønsker å oppnå med overgangen til skyen. Vi mener du bør vurdere spørsmål som:

• Hva er hoveddriverne for migrering? (f.eks., kostnadsreduksjon, skalerbarhet, forbedret ytelse)
• Hvilke applikasjoner og data trengs å flyttes?
• Hvordan vil skyadopsjon påvirke din nåværende arbeidsflyt og tjenester?

2. Planlegg migrasjonsstrategien

Velg en migrasjonsstrategi som passer for din virksomhet. Det er flere strategier, eksempler kan være:

• "Lift and shift" (rehosting), hvor applikasjoner flyttes til skyen uten endringer.
• Refactoring, hvor applikasjoner endres for å optimalisere ytelsen i skyen.
• Replatforming, hvor du gjør noen få endringer for å dra nytte av skybaserte teknologier.

3. Sikkerhet og samsvar

Sikkerhet er helt avgjørende når det kommer til skyinfrastruktur.

• Hvilke sikkerhetsprotokoller tilbyr skyplattformen og hvordan kan du integrere disse med dine eksisterende sikkerhetssystemer?
• Hvordan vil du håndtere identitets- og tilgangsstyring?
• Sørg for å forstå regulative krav som påvirker din bransje når det gjelder datalagring og -håndtering.

4. Kostnadsstyring

Skyleverandørene tilbyr en pay-as-you-go-modell, men det kan likevel være utfordrende å kontrollere utgifter uten riktig styring. Det finnes flere gode verktøy som kan og sette opp både budsjetter og alarmer for å holde øye med kostnadene.

5. Teknisk support og kompetanse

Overgangen til skyen krever teknisk kompetanse. Vurder følgende:

• Har ditt nåværende team de nødvendige ferdighetene og sertifiseringene, eller trenger du å ansette nytt personell eller søke ekstern hjelp?

Redpill Linpro er AWS Advanced Partner og AWS Solution Provider(SPP). Vi har jobbet med skyteknologi og -løsninger i over 10 år. Vi har den rette kompetansen og erfaringen for å hjelpe deg på din skyreise. Tilbakemeldingene vi får fra markedet er at kundene ønsker å fokusere på utvikling av egne løsninger og ikke drift. Derfor er Redpill Linpros Cloud Management en av de viktigste tjenestene vi tilbyr våre kunder.

Det å migrere til AWS kan endre din IT-infrastruktur på mange positive måter. Ved å ta hensyn til punktene ovenfor, kan du navigere effektivt i overgangen og utnytte fordelene med skyteknologi maksimalt.

• 5 reasons to move to the cloud
• 5 things to consider when migrating to the cloud
• 5 things to consider when choosing a provider
• 5 challenges
• 5 opportunities

1. You can avoid investing in your infrastructure and instead buy the specific services your business needs at any given time.
2. The flexibility is unlimited. You start with the capacity your company currently needs and can scale up or down as your business evolves.
3. There are many services offered by public cloud providers. However, these services are standardised, so if you want to customise them to your specific needs, it is good to seek help from a partner who can assist in meeting those needs.
4. You can avoid being trapped in long contracts; you can move in and out as needed.
5. The services in the cloud are automated.

1. Ensure that your security and regulatory requirements are met. For example, where is your data stored, who has access to it, how long are backups retained, access control, and GDPR compliance are some factors to consider.
2. Identify shadow IT that is beyond the control of the IT department. Parts of the business may have purchased systems that IT is unaware of and that could be critical. Find out if any exist and consider them before moving to the cloud. Communication between IT and the business is crucial!
3. Automate internal processes. Cloud services are automated, but make sure that internal processes do not become bottlenecks.
4. Inventory what can be moved to the cloud. Applications supporting core business functions, especially older applications, are often customer-specific, complex, and integrated. Some applications are not suitable for migration to the cloud, while others are ready for migration.
5. Choose a provider carefully. "Everything fails all the time" is a well-known quote from Werner Vogels (CTO Amazon). Can the application handle these conditions? Who manages errors, upgrades, and changes after a move to the cloud?

1. Experience in helping customers migrate to the cloud with the right expertise in the field and acting as advisors before and during the migration. Ensure they can handle your new environment where all or part of the environment resides in the cloud.
2. Ensure the provider can deliver the services your company needs. For example, that they can offer services related to databases, networks, applications, security, DevOps, analytics, AI, agile IT operations, etc. The provider should be independent of where your infrastructure is located, meaning that they can offer Cloud-independent technology allowing hybrid operations and the ability to move your infrastructure to other cloud providers.
3. Ensure the provider has experience in handling lock-in effects and designing to work around them when necessary. Seek help from the references the provider has assisted in the past. There is plenty of advice and tips available, so take advantage of their experiences.
4. Cloud price models may be quite complicated. Ensure the provider can give you a sustainable estimate of the cost of the migration and the new environment. Once you’re up and running, make sure to bring a partner experienced with cost management and cost optimalisation along.
5. We all have a responsibility for the environment. Ensure that your provider values the environment in their work practices.

1. Maintain control over data, who has access to it, how long it is stored, and where. Keep a back door open through external backups to take responsibility in case of major failures and bring up the environment externally.
2. New work methods/tools to learn, and we humans can sometimes struggle to embrace the changes.
3. Choose environments where you have the most to gain and prioritise moving them to the cloud first.
4. Review internal procedures and processes and automate internal processes. As mentioned above, internal processes are often bottlenecks and need to be reviewed for efficient delivery. Adapt routines to the requirements and challenges of moving to the Cloud, including making applications redundant and quickly recovering from errors.
5. Skills development for the staff affected by the change.

1. Set up a new test or production environment in no time.
2. Easy to scale correctly.
3. Always a modern platform.
4. More time for proactive work. Your own resources can spend more time developing instead of managing their environment.
5. Higher competitiveness. Smart cloud-based solutions can make your business more competitive. Cloud service providers can often offer systems with high performance, and due to economies of scale, even small companies can use the same tools and applications as large enterprises.

Read more here or contact us for a cloud chat through our contact form.

In this blogpost, we'll explore how to get involved in CNCF(Cloud Native Computing Foundation) open source projects, what knowledge you need to contribute, and how to become part of this community.

Here are a few perks of contributing to open source, aside from making a positive global impact and ensuring software remains freely accessible for anyone:

• Gaining important skills, knowledge and learning from a global community of developers.
• Fixing that irritating bug or translation issue that has been bugging you for ages.
• Being able to add needed features to the software you've been using.
• Rather than implementing workarounds in your software, which relies on an open-source project, consider addressing the issue at its root. By fixing the underlying problem, you can ensure that your software remains stable for the foreseeable future.
• Participating in open-source projects can significantly enhance your personal growth and may also bolster your prospects in job hunting or exploring intriguing opportunities in the tech field.

Of course, there are several important aspects of open source that Non-Code Contributors can help with:

• Documentation and Guides: Writing clear and comprehensive documentation can significantly impact a project's usability and is an important part of the software’s lifecycle. 
• UX/UI Design: Elevate the user experience by enhancing the visual and interactive aspects of the project. Designing user interfaces, improving accessibility, and ensuring a seamless, intuitive experience not only boosts overall software quality but also aids developers in coding new features more effectively.
• Bug Reports and Issue Management: By creating, filing, and updating bug reports you help developers with the testing of the software and make sure that annoying bugs get fixed.
• Translation services: Translating project documentation, user interfaces, and other communication materials into different languages enhances accessibility and extends the global reach of the open source project.
• Community Engagement: Actively participate in community discussions, welcome new members, and contribute to a positive and inclusive atmosphere. Your input can be invaluable in shaping the project's direction and fostering a collaborative environment.
• Moderation and Civility: Volunteer to moderate discussions and ensure a civil and respectful tone within the community. This encourages a welcoming space for everyone.

Not quite, there are still some important prerequisites to keep in mind before contributing to open source projects:

• Both technical and non-technical contributors should understand some basic Git, pull requests, and issues. Version control management tools are usually used to manage contributions and track changes of contributors. 
• You need programming language proficiency and familiarity with testing frameworks if you would like to become a technical contributor. What kind of programming language is needed depends on the project you are interested in.
• It's great to have some knowledge about basic security measures like SSH keys and 2FA(two-factor authentication). These measures ensure secure contributions in the projects. You can usually find information about the security measures in the project documentation. 

Here are the 5 steps of getting started with contributing to CNCF technologies: 
 

1. Join the Community - The first step to contribute to open source is to join the community around the technology. Most open source projects have slack or GitHub repositories where you can find information on how to contribute. It's important to read and follow the community’s guidelines, to ensure a successful collaboration.
2. Choose a Project - Selecting the right project for you is critical. CNCF hosts numerous open source projects in the global cloud-native ecosystem. Explore the Cloud Native Contributor page to discover an extensive list of projects available for your contribution, categorized by programming language and maturity level. Consider your interests and skill level when choosing a project. Being familiar or regularly using the open source project before contributing is essential. This helps you with the understanding of the architecture and software functionality. If you use the technology regularly you also gain insights into the project's bugs, features and of course how to improve them.
3. Documentation - Before contributing, take some time to properly read the project's documentation, including all README files and contribution guidelines. Explore potential forums and open/closed issues and pull requests. This knowledge will provide insights into the project's context, goals, and challenges, and will also guide you for example on the intricacies of writing effective pull requests.
4. Collaborate with Others/Asking for Help - Open source is all about coming together and working as a team. Reach out to other contributors for help or feedback if needed. Help other developers by reviewing code, providing feedback, and testing their changes. Building relationships with contributors and improving skills through collaboration is key. However it is important to remember to attempt to learn before seeking assistance. Many open source contributors do this in their spare time so try to limit seeking general mentoring of programming languages. Don't feel discouraged if you don't get help immediately, usually there is a time zone difference and they might not have seen your requests just yet. 
5. Contribute - It's time to do the work! Brew yourself a large cup of coffee and dive right in. It's best to quickly rip off that bandage and start coding. Tackling a series of smaller issues or tasks will boost your confidence, enhancing your skills and knowledge along the way. Submitting a pull request for testing and general feedback, even if the problem isn't fully resolved, is preferable to not submitting one at all. Other developers can pick up where you left off or help you continue on your journey.

Start Small

For beginners, starting small is crucial. Look for easier issues or small features to gain familiarity with the project's codebase. As you gain experience, then you can tackle the more challenging tasks. Remember, every contribution counts!

Glossary

If you stumble upon words or acronyms that seem outlandish to you then here is a great glossary that covers frequently used CNCF-specific terms.

Explore and join a Mentoring WG (Mentoring Working Group)

Through the Mentoring WG, individuals can explore various mentorship opportunities. Mentors, who are typically experienced contributors in the CNCF community, offer guidance and support to mentees looking to enhance their skills.
This is a great opportunity if you are new to contributing to Open source and cloud-native technologies.

Mentoring WG also manages the following mentorship initiatives:

• LFX Mentorship (ex-CommunityBridge): mentoring initiative by the Linux Foundation - details
• Google Summer of Code: mentoring program for the open source beginners - details
• Google Season of Docs: mentoring initiative for the technical writers - details
• Outreachy: mentoring initiative for the communities traditionally underrepresented in tech - details

Embarking on the CNCF open source journey opens doors to collaborative innovation. Whether a developer or non-code contributor, the benefits extend beyond the technical realm, fostering skill growth and global learning. Collaboration is key, so seek assistance and contribute at your own pace. Each contribution contributes to the collective progress of open source. Embrace the journey, as well as the learning experiences, and become an integral part of this dynamic ecosystem.

Happy contributing!

Building new technical solutions requires adherence to speed, scale, and high availability on a global scene. The Cloud Native Computing Foundation aims to provide an overview of the open source market options that satisfy the requirements of cloud native. Some of them are probably familiar since before; common names like kubernetes, helm, cri-o. Others are not as familiar. Particularly if you’re scrolling cncf.io/projects and go down to incubating, and sandboxed projects. The list… Well, it goes on. And right at the side of all the eccentric logos is another link, named view on cncf landscape. You click that, and find yourself falling down a rabbithole of squares within squares within more squares of too many graphic symbols. 

Welcome, you have found your way to the Cloud Native Landscape.

The first thing that meets the eye is that there seems to be some sort of system as to how the projects are categorized, after all. We have these shaded blue delimiters with names. To the right, vertically, we have main categories. App definition and development, orchestration and management, runtime, et cetera. If we’re zooming in on the first main category, App definition and development, we can see horizontal headlines as well; Application definition and image build, Continuous integration and delivery, Database, Streaming and messaging. 

Within each category, the apps are two sizes. If they’re bigger, they are featured; in the Projects and Product group, this means that they are an Incubated or Graduated project. We’ll come back to what the meaning of groups is.
The small size apps are sandboxed. This is the entry level classification for projects that qualify for the CNCF early stage requirements. The project classifications and project proposal process is a chapter on its own and will not be discussed in detail here.

Next to the horizontal subcategory name, there is a small book symbol. It is a highlight link to the Guide chapter for this specific subcategory. 

The Cloud Native Landscape page has a top grid with three headlines: Explore, Guide, and Stats. Explore is the page with the graphical landscape itself. The Guide page is a comprehensive guide to the different subcategories of Projects. 

The guide describes each project subcategory by four compartments: what it is, the problem it addresses, how it helps, and technical 101. It even includes associated buzzwords, and, of course, a graphical presentation of the associated projects.

The Stats is a common stats page for the Cloud Native Landscape as a whole. In addition, if you click on a project, and click on the staple diagram symbol (not all sandboxed projects has one, but those who do) you will find the devstat grafana page with interesting statistics on that specific project. You can also find the devstat page by navigating to https://projectname.devstats.cncf.io/.

Now, the landscape is not all projects. Remember that we would get back to groups? Projects and products is the default group, but if you look at the top of the projects, you’ll see that you can switch between an additional four groups;

The Member group shows what members are Platinum, Gold, Silver, End User Supporter, Non-profit, or Academic. They all come with their respective rights and commitments.

Certified partners and providers are members who are eligible for specific roles. They might provision kubernetes as a platform offer, or fulfill the requirement of being a certified service provider. 

Moreover, there are groups specifically for serverless and webassembly offers.

The Cloud Native Landscape aims to provide an overview over the whole CNCF universe, projects and members alike. You can search for items or filter the view, there are options for downloading an overview pdf or png, or the raw dataset. The Landscape project adheres to the CNCF project requirements and is openly accessible on GitHub.

Hopefully this overview can ease the cognitive load of a first time navigation of the Cloud Native Landscape. Once the landscape starts to feel like known waters, it will significantly help in the decision-making whenever a new cloud native solution is considered to find the best fitted solution in this ever-changing digital world.

*Disclaimer: This material is for educational and informative purposes only. Redpill Linpro is a member of the Cloud Native Computing Foundation (CNCF) and a sponsor of CNCF related events, but is not otherwise economically affiliated or sponsored by CNCF.

Established in 2015 under the umbrella of the Linux Foundation, CNCF serves as a vendor neutral home for open-source projects that collectively define the landscape of cloud-native computing. From container orchestration to monitoring and beyond, CNCF projects are crucial to many cloud engineers and open source enthusiasts alike.

By providing a collaborative platform for developers, end-users, and vendors, CNCF fosters an environment where ideas and technologies evolve. Moreover, CNCF sets standards through courses, certification programs and expertise. It is not just an organization; but rather a catalyst for progress in the ever-evolving cloud tech landscape. Under the CNCF umbrella many projects have grown and evolved.

The organization's projects are grouped into 3 categories: sandboxed projects, incubated projects, and graduated projects. Ranging from early stage projects to mature, stable and finalized “in production” projects.

You may know or use some of these graduated technologies daily, such as:

● Kubernetes - a system for automating deployment, scaling, and management of containerized applications,

● Prometheus - monitoring and alerting,

● Argocd - continuous integration and delivery,

● Cilium - cloud native network,

● Helm - application definition and image building,

● Containerd - container runtime,

… and many more.

We will actively participate and attend meetups in Stockholm, Oslo and Aarhus.Some of us will also partake at CNCF’s flagship conference ”Kubecon” in Paris, from 19 - 22 March, 2024. This means that you can expect IT talks (our very own podcast), blog posts, live/video talks and a lot more in 2024.

We will also host our very own CNCF meetups with interesting tech talks and demos to actively participate in the community. We are very excited about this opportunity. Hopefully you are, too!

Our journey into the CNCF universe marks a new and thrilling chapter in our commitment to innovation and open-source excellence. As we embark on this partnership, we are not merely aligning with industry standards; we are diving into the forefront of cloud-native evolution.

We invite you to join us. Keep an eye out for invitations to meetups and digital events.

Service A is unexpectedly flooded with requests, bottlenecking the data throughput. It’s 5 pm and the IT folks have already left for the day. The stream is rapidly growing until a built-in queue limit is hit, and data is dropped. The data is collected for a time-sensitive project that depends on full series for correct display of statistics. When the data team arrives, the statistics are largely skewed, and the batch is useless. Everything worked the day before, and suddenly, the service couldn’t handle incoming requests. Clearly, someone has done something. Who pushed the change? And why hasn’t anyone implemented any alert triggers?

Incidents take an infinite number of shapes. Not all scenarios can be tracked to a persons’ specific action, but even if it’s not, it’s still easy to put blame on the people, team, or managers who let things happen or not happen. If the goals for implementing monitoring had been reached, if the program had been updated properly, if the push hadn’t been implemented at 5 pm.

Every incident, no matter how minor, should be followed up with an event called Post Mortem. The Post Mortem are the actions and reporting of the timeline of the incident, an analysis of what went well and what could have been done differently, and a list of action points to prevent the incident from occurring again. The Post Mortem can be a meeting, a presentation, or a mail conversation, resulting in the writing of a Post Mortem report. It is considered good practice to define a format for the Post Mortems. Well performed, the Post Mortem turns into a valuable learning opportunity for anyone with an interest in the system and processes involved - not just the ones who might have worked with the incident directly.

Ok, so the Post Mortem routine is defined, you created a new repository for Post Mortem Reports and you are a little eager to implement the procedure at the next incident. But you hesitate. The idea is fine, we should learn from mistakes. But putting peoples’ failures into printing is so invasive. Who would ever want to stand up and get their name on a report of failure?

The thing is no one will have to do that. There is a twist still uncounted for, as originally defined by the LEAN framework:

People don’t fail. Processes do.

People define processes, and people also redefine, adapt, and improve on processes. To identify why a process failed given the information, environment, and tools at hand at that specific point in time, there is another component from the LEAN framework that is useful:

Investigation A (blaming):

Who navigated the boat into the iceberg? (Awkward silence, not a very productive conversation.)

Investigation B (1 WHY):

Why did the ship sink? - It hit an iceberg and broke. (Ok, check, don’t hit icebergs and don’t break. But maybe there’s more to investigate?)

Investigation C (5 WHY):

Why did the ship sink? - Water filled the hull.
Why? - The hull was ruptured.
Why? - Titanic hit an iceberg.
Why? - Ship turn and maneuver inefficiency
Why? - Ship speed

You can dig deeper with more whys or branch out to a different approach (Titanic hit an iceberg > lookout reported iceberg too late > lookout couldn't see iceberg, it was dark, OR Titanic sank > water filled hull > openings in hull > steel plates pulled apart on hull > strength of overlapping joints and rivets). All these approaches lead to conclusions that are accurate, in their different ways, and can be used to define action points to prevent a specific event from reoccurring.

A Blameless Post Mortem teaches what processes that are just right, what could be improved, and most importantly, what processes to avoid that would otherwise lead to exactly the same situation the next time the problem occurs.

Consider the effects of your team, or an individual, being paralyzed by fear and keeping learnings from an incident process to themselves. The risk of the incident reoccurring increases by the number of process failures.

There are on-call tools that come with a built-in Post Mortem feature, conveniently integrated with systems for alerts and ticket creation. The two market leaders, PagerDuty and Atlassian’s’ OpsGenie, both have a Post Mortem feature.

On the Open Source side, there is etsy/morgue, a Post Mortem organizer that integrates with IRC and Jira.

Google provides a Post Mortem template deriving from their internal blameless Post Mortem process: https://sre.google/sre-book/example-postmortem/

As for service A, the engineer who investigated the issue remembered to write down the steps taken to narrow down and mitigate the problem. He noted any out-of-the-ordinary observations on the way, as well as areas of improvement that might not have been the direct cause of the issue but would be good to tighten up. He took some fast notes of what alert points to implement to be able to react timely the next time a data batch would be at stake. Three days later, a Post Mortem meeting occurred, and the teachings were shared both in an internal memo, and as a light-themed post on the internal Friday share meeting.

By planting a distance between the engineer and the incident and conducting information on the incident as a “show and tell”, a great deal of the stigma of failure is removed. When there’s less space for fear, there’s more space for focus on improvement of the infrastructure and the incident response process.