Hitchhiker's by eng osama

The Hitchhiker's Guide To The Cloud-native Galaxy

Table of Contents

1. Cloud-Native Software Development & Operations

2. Understand The Impact Cloud-Native Will Have On Your Business

3. Everything Will Change

4. Adapting Your Application

5. Start Your Assembly Line With Kubernetes

6. Automate Your Deployments

7. Observability

8. The Journey Continues...

1. Cloud-Native Software Development & Operations Congratulations! You’re taking the first steps towards leveraging Cloud-native software development and operations in your organization. While this journey may seem daunting, there are many reasons why organizations are continuing to adopt Cloud-native. This guide is intended for those who have decided to take their first steps towards Cloud-native but are unsure of everything that is required of them to complete their transformation. Before we dive in, let’s take a brief moment to define Cloud-native. Cloud-native is an approach to help organizations construct, maintain and scale their applications. The demand for uninterrupted 24/7 service supporting the entire world endures challenges that many companies continue to solve. With Cloud-native, we can learn from the experiences of others, adopt widely-used design patterns and leverage open-source software to help your business meet that demand.

1.1 It’s Hard, But Not Impossible There is no denying it- software is eating the world. Whether you’re building an app or scaling your SaaS offering, your users expect the latest and greatest features to run perfectly. Delivering on those expectations is challenging- but not impossible. We see it achieved every time we open an application to get work done, order something to eat or refresh our social media feeds. As software continues to play an integral role in our lives, ensuring an uninterrupted experience is critical to any business or lifestyle. Rapid application delivery at the highest quality is difficult because it takes more than just a suite of software for your applications and organization to run optimally. Implementing a suite of software services are useful when applied appropriately, but can also be disastrous if picked at random. What do you do if the tools you're using don’t fit into your organization’s work style? The way you work together should be represented by a solution, not the other way around. PRO TIP: Understand your team’s workflow before shopping around for a new management solution.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Letâ&#x20AC;&#x2122;s take the common situation of workplace silos. Even with a variety of tools available, communications still break down. Functional teams are unaware of any ingress updates, resulting in a cascading set of delays and rifts. An increase in tension will drive large wedges between your Engineering, Product and Business teams, ultimately bringing your business to a halt. Why do you think this happens? Hint: itâ&#x20AC;&#x2122;s definitely not due to a lack of tools. Real-time chats and email have been around even before the Internet. In most companies, an organizational chart outlines the way teams are structured. They have also dictated how we work together. In this model, workplace silos are created by design. If we built an entire application over a long development cycle

with few changes to the requirements, these silos would work due to the small amount of inter-team communications necessary. In dynamic environments where beta is now production and changes are made as quickly as possible, the inherent lack of communication in a siloed model makes delivering quality software at a rapid pace difficult to maintain. Cloud-native can help transform those siloed functional teams into dynamic delivery teams to continuously meet the demand of the biggest stakeholders- your user community.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

1.2 Three-Stage Transformation Although your business goals are different than ours, the need to deliver at an ever-increasing pace rings true more now than ever. The way we used to do things just doesn’t work anymore. Things have changed. We need to understand how to adapt to today’s demand while dealing with what is now a legacy stack. We've developed a three-stage approach to help organizations increase their chances of a successful transformation. We’ve discovered that going Cloud-native to seed your next feature can kickstart your efforts of building a robust organization that automates most things while working on the hardest things. The first stage of your Cloud-native transformation is about working with your teams to set your goals. Understanding and evangelizing the benefits of Cloud-native can help on-board those who are unfamiliar with the concepts while reinforcing your strongest enthusiasts. Give your teams a good reason for change. If you tune into what’s happening on the ground, you'll discover commonalities amongst your teams. Use this as a basis to widen your communication channels. Shift your teams’ focus to your biggest business challenges, and I'm sure they’ll provide some interesting feedback. That’s the point. Your teams should be highly engaged. Pro Tip: At first, the initiatives should be driven top-down. The changes should come from the bottom up. The second stage of your transformation is the proof-of-concept stage. Formalize a project and task the first cross-functional delivery teams to work off Cloud-native principles and technologies. Scope a small project to deliver your first containers to a container orchestrator (We’ll cover these in-depth later in the book). In this stage, processes begin to shape as your new teams begin to figure out how to work with each other. The third stage of your transformation will take what you have learned about your people, processes, and technical capabilities and apply them to production. It is here that your teams can start to self-organize and collaborate freely, changing the way you manage your applications. Automating deployments and standing up production support systems clears the stage and makes room for the next development cycle. Your initial rollout will not be perfect. It will be normal to feel a lot of weight on THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

your shoulders. To ease some of that load, get your teams involved in some of the decision-making. Gather feedback early on if your teams are willing to give it and small adjustments based on what you receive. When building an environment that acts as it learns, you’ll be surprised by how today’s issues quickly become distant memories. Pro Tip: Some people will need to feel extremely comfortable before offering candid feedback, especially in a group setting. Although it might be on you to lead a transformation, it takes an entire team to transform. By incorporating change into your process, your team knows they’ll be solving the problem they were brought on to solve, not the problem of how to solve a problem.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Stage One Transformation Goal Setting And Team Preparation

2. Understand The Impact Cloud-Native Will Have On Your Business Before we discuss the technicalities of Cloud-native, we need to examine how becoming a Cloud-native organization can help your business. Cloud-native applications can help you release features faster, accommodate growing user demand, and build a level of confidence that will be required when building your next-gen feature.

2.1 Scalability & Flexibility Cloud-native architectures are built upon microservices. In a monolithic application, allocating more computer resources when scaling vertically can be inefficient since the resources are spread across the entire application. With microservices, each service is allocated its own set of resources, allowing for adjustments at the service level. The same rules apply when scaling horizontally. When an Nth replica of a microservice is scheduled, microservices are replicated at the service level instead of the application level. Scale your application piece by piece, not all at once. Cloud-native applications are flexible since they are designed to be run virtually anywhere there is container support. This frees you from infrastructure lock-in. In many cases, abandoning existing infrastructure is unfeasible, and adding new systems can be difficult. Bring your own infrastructure if you wish. Cloud-native applications reside in a different layer than your serving cluster, saving most of us from having to rebuild systems from the ground up.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

2.2 Deliver Fast, Deliver Often When your teams are empowered to do what they do best, a Cloud-native application can be released quickly- and frequently. Systems engineering teams spend time building robust automated systems so software engineering teams can become NoOps teams; building, testing and deploying their containers to any environment they wish. There is no â&#x20AC;&#x153;throwing it over the wallâ&#x20AC;? here. Software engineering teams are fully responsible for the functionality and release of their microservice. Since microservice applications are split into loosely coupled services, feature development is contained within smaller chunks. Software engineering teams no longer need to understand the complete architecture or reverse-engineer mysterious behavior in order to build something new. You can build multiple disparate features in parallel without having to worry too much about existing dependencies you'd normally find in a monolithic application. Once your code is ready for production, your software engineers can deploy, hotfix, and continue to monitor their services until they are assured the bug has been squashed- all without contacting other teams. The same deployment procedure and tools for non-prod environments can be used for production, taking advantage of your team's familiarity with the procedure. THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

To tie it all together, a critical component to rapid delivery is having an easy-touse deployment solution. Ease of use increases usage frequency. The more a team deploys and tests, the higher the likelihood of discovering a problem before entering production. An intuitive UX can make all the difference. The last thing you want is yet another clunky system that nobody wants to use.

2.3 Confidence Practice makes perfect. When youâ&#x20AC;&#x2122;ve pressed the button a million times, pressing it one more time is a no-brainer. This is the type of confidence your teams should have when deploying. As your tests prove themselves worthy, replace human initiation (and error) with automation, and let the machine tell you when something is wrong. No one should be afraid to deploy. Fear will drive deployment paralysis and bring your innovations to a dead stop. There are many reasons why teams are afraid to deploy, from anxiety due to the number of changes released at once to fearing the unknown results of what a deployment may bring. These types of fears can be addressed by simply doing the opposite. Deploy a smaller number of changes often and continuously test them. 10

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

At the other end of the spectrum, frequently delivering high-quality services proves to your user community that your next anticipated feature will work as advertised. Your organization’s reputation will spread throughout the community, so how “right” you get it can mean the difference between virality and attrition.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

3. Everything Will Change As with most modern-day software projects, implementing the necessary changes to your organization will require time, purposeful decision making, maintenance, and even trial and error. Most importantly, there will be a change in team composition that will require an adjustment from everyone involved.

3.1 Culture Pro Tip: Establish your cultural values, and then add the right combination of process and technology to propel you to the next level. Organizations today flock to DevOps because of its proven value, often under the false guise that DevOps is a suite of tools, or “CI”. DevOps isn’t a suite of tools, but a culture of working together to quickly deliver reliable software. By implementing standards, teams can structure their workflow to measure their own velocity, set realistic delivery goals, save time, and continuously improve.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

DevOps began as a way for software and systems engineers to work together instead of against one another. Today, the collaborative nature of DevOps extends to software engineers, systems and reliability engineers, quality engineers, product owners, etc. These individuals are grouped into one team responsible for delivering a feature, which is what we call the delivery team. Every member of the team contributes to the success of the project by fulfilling the tasks that fall within their domain. Each member of a delivery team can add a diverse perspective to the discussion. Including the appropriate team members at the beginning of the project allows for a shared context and a common understanding that helps the team move in the same direction from the very start. Delivery teams might replace functional teams when working on projects, but they don't eliminate the need for them. People would still remain in their own functional teams, each with their own set of rules, roles, and responsibilities. Delivery team members should be following standards set forth by their functional team. From a software engineering perspective, these standards could be a particular branching strategy or coding style. In any case, they are to be applied unanimously if standards are to be kept.

3.2 Process Youâ&#x20AC;&#x2122;ll be hard-pressed to find an organization that has adopted a DevOps culture without a process to help manage their initiatives. With the many flavors of process management out there, each organization will have different reasons for picking one methodology and framework over another. All methods have their pros and cons, but each method is meant to solve the same set of problems in their own way. The reality is there is no one-size-fits-all model. Itâ&#x20AC;&#x2122;s not uncommon to implement a hybrid process composed of bits and pieces from different frameworks, like Scrum or Kanban, and then applying what works best for the team. An example would be having a daily stand-up meeting asking what you did yesterday, what you did today, and communicating out if you are blocked (Scrum), but then huddling around a Kanban board. Having a process that reflects the most efficient way to get things done is critical. People cringe when they hear the word process, so be sure every step addresses THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

a need as simply as possible. In the beginning, your goal is to build a strong foundation to start from. Before building from scratch, know what your teams are familiar with. Offering your team a chance to share their own experiences of “what worked well at Organization X” can build inclusion while establishing points for discussion and consideration. Whether it’s a limited number of tasks at a one time (Kanban), or a group of tasks over a duration of time (Scrum and sprinting), you need to strive to establish a delivery schedule. Non-technical stakeholders always want to know when a feature is getting released. Humans can severely underestimate how long things take to build, so answering that question without any data is impossible. Rely on recording and measuring your team’s velocity (Scrum and story points) to base estimates on similar work completed in the past. Finally, make sure the meetings you’re having are important. Meetings should have an established agenda and clear objectives so you don’t suffer from “meetings to meet about the next meeting” syndrome. Remember to reserve one-on-one times so everyone has an opportunity to express their opinions and receive feedback. Get familiar with the concept of a parking lot, or having interested parties defer a deviating conversation outside of the current meeting. Pro Tip: Don’t meet just to meet. Meet with a purpose.

3.3 Technical Skills

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

There will be a new set of technologies that your software and system engineers will have to learn. The core four in a Cloud-native stack are Microservice Architecture, Containerization, Container Orchestration and CI/CD. Your teams will have to learn how to build and configure microservices, containers and the systems they run on. Fortunately for us, the Cloud-native community is alive and very active. Training materials and well-documented, production-grade procedures are widely available. In the next stage, weâ&#x20AC;&#x2122;ll walk you through the hands-on steps you and your teams will take to turn your transformation into a reality.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Stage Two Transformation Proof - Of - Concept

4. Adapting Your Application A Cloud-native application is built for scale. It begins with the building blocks; containers and microservices. As you start rolling up your sleeves, ask yourself some basic questions. How will the microservices communicate with each other? How do you deal with the state between services? Can your microservices be stateless? How can you take advantage of the cloud and elasticity? As you begin to build things out, questions like these will present themselves as the next item in your backlog to be solved. In this part of your transformation, youâ&#x20AC;&#x2122;ll get a firsthand perspective of what old problems have magically disappeared, how your current questions get answered, and what new challenges await.

4.1 Containers Itâ&#x20AC;&#x2122;s impossible to write about Cloud-native without mentioning containers. Containers represent a common, deployable artifact that allows for software to be run virtually anywhere. Leveraging containers as this common artifact removes the management overhead of build systems and runtime environments stemming from the use of various programming languages. Instead of your development teams passing this information off for another team to manage, they can now add their specific version of packages, as well as other dependencies in a self-contained unit. Your dev teams will have complete control over how their microservice is packaged.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

4.2 Microservice

Every organization is different, and in some scenarios, a microservice architecture might not provide any value. In organizations that are able to make the switch, building microservices within containers gives you options. Each microservice is divided into its own process and could potentially be managed by its own team, aligning your delivery team with business requirements. Remember: one of our goals is to build delivery teams from functional teams. Pro Tip: Prepare your software engineering teams for an increase in responsibility. Whether you are building from scratch or migrating from a monolithic application, microservices may solve a few scalability challenges for you. However, they could also introduce new ones. Adding numerous services to perform specific functions can be overwhelming to manage. Ensure your team is well equipped to support the level of distributed services you are implementing.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Building an application using a methodology standardizes your microservice structure. Newly-created microservices can benefit from build templates and existing delivery procedures. From the outside, it’s just another container getting built, deployed, and tested. Spend more time building business logic and less time reinventing the wheel.

4.3 Local Development When you finally start building out your microservices, you’ll probably be looking at Docker for containerization. A good first step is to try and build your monolith all within a single Docker container (or a hello-world walkthrough). There are official base containers of many programming languages to give you a head start, but you can also dive headfirst and build yours from the ground up. When you’re done, push it up to your container registry so it can be deployed later. A goal would be to recreate your entire stack all on your local machine.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

5. Start Your Assembly Line With Kubernetes Container orchestration at scale. With your software engineers having full control over their microservice, your systems and reliability engineers can now spend fewer cycles managing individual components and servers, and more time focusing on operational efficiency and continuity.

5.1 Infrastructure As Code (IAC) The lowest layer of your stack is the serving infrastructure. Whether you are selfhosted, in the cloud, or working in a hybrid situation, you need to account for the provisioning of your compute resources. Today, you can store your infrastructure configurations in your source code repository and re-apply Cloud-native principles, processes, and tools to version, deploy and test your serving infrastructure alongside your microservices. 20

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

5.2 Container Orchestration Once your application is broken down into containers, you’ll need a way to manage the lifecycle of your containers. A container orchestration layer is responsible for : y Hosting containers and their configuration y Deploying and removing containers based on a number of factors such as available compute resources or dedicated nodes y Providing container redundancy and availability y Load balancing between containers y Monitoring the health of a container As you search for a container orchestrator, you will come across Kubernetes. Kubernetes has become the most widely adopted container orchestrator in the space, empowering many of today’s Cloud-native businesses. It’s an open-source project specifically designed to include all the features listed above. Kubernetes adoption stands at 86%, but the way Kubernetes is deployed has changed dramatically. - Stackrox https://www.stackrox.com

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Kubernetes can be run wherever Linux is served, and can be self-hosted, self-managed, or fully managed by a 3rd party. Due to the wide adoption of Kubernetes, the remainder of this guide is based on implementing Kubernetes as your orchestrator. Again, you can bring your own infrastructure if you need to. Kubernetes and its orchestration power reside in a layer apart from your servers. Pro Tip: There are other container orchestration tools in the market, but be mindful of the support you will receive from using tools that arenâ&#x20AC;&#x2122;t as well supported as Kubernetes.

5.3 Manual Deployment With a container image in the registry and an orchestration system provisioned, your team should try deploying a container to your orchestrator. When using Kubernetes, the ability to deploy requires access and permissions to the Kubernetes API. You will have a problem extending out user permissions to your software engineers because Kubernetes doesnâ&#x20AC;&#x2122;t have a native concept of user accounts. In this case, your cluster administrators will most likely have to deploy using the credentials created during installation. Once the container is successfully deployed, there is still a bit more work to do. Do other microservices need access to it? Do you need to access your microservice from outside of Kubernetes? These are just two questions your teams will need to answer when designing your application. This proof-of-concept stage is done when your teams feel confident with the process they've developed and the tools they've implemented.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Stage Three Transformation Moving Into Production

6. Automate Your Deployments As your proof-of-concept wraps up, your production readiness begins. Your manual deployments can still work, but in order to obtain the high throughput that Cloud-native offers, you have to iteratively build on top of what you have learned in the previous stage. It's time to automate. In 2019, the Cloud Native Computing Foundation surveyed organizations and discovered the adoption of daily releases increased from 15% in 2018 to 27% in 2019. Weekly release cycles also increased from 20% to 28%. Every day, more and more organizations are adopting Cloud-native and taking advantage of its benefits.

Image from CNCF - https://www.cncf.io/blog Stage two of your transformation focused more on learning to work with your new stack and each other. Along the way, you may have realized those manual tasks became repetitive. To kick off stage three, weâ&#x20AC;&#x2122;ll turn that repetition into automation. Pro Tip: Start testing early in the development cycle and deploy often so your good 24

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

habits will be hard to break.

6.1 Continuous Integration (Ci)/Continuous Deployment (Cd) Initially, managing a handful of deployment and configuration files shouldn’t yield too much overhead. As the number of microservices increases, managing deployment chains with different versions of the code scattered everywhere can become overwhelming. We can do a better job of managing complex pipelines.

Continuously integrating (CI) your branch of the code with changes implemented from others helps discover issues faster. The integration process typically consists of unit testing, software compiling and preparation for deployment. As your team works on the same code base and files, CI solves the problem of making sure everyone’s work integrates well altogether. Continuously deploying (CD) means automatically deploying your software as soon as it’s available. In a perfect world, your CI/CD pipeline has checks in place to safely deploy to production automatically without human intervention. For those that aren’t quite there yet, CD can also mean continuous delivery. The big difference between the two is that with continuous delivery, deploying to production requires a human to proceed. A complete CI/CD pipeline will replace manual deployments by initiating from an event-based trigger. This trigger is usually an activity that already exists in your development workflow, such as merging changes into your mainline branch or THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

requesting a code review. Instead of passing the responsibility of building and deploying to another team, you can use an event to trigger the building, testing and deployment of that code to any environment set in the pipeline.

Building a pipeline with multiple steps is a core feature of most modern-day CI/CD solutions. Use these additional steps to test your software as soon as you can. This is when the benefits of Cloud-native really begin to shine. Place tests in your new pipeline where they make sense and trigger subsequent actions based on those test results. For more information about CI/CD visit our blog Here

6.2 Centralized CI/CD In large enterprises, it might make sense to decentralize your CI/CD solutions. However, for smaller organizations, especially when starting out, using a centralized system will ease adoption. If you want to establish a standard deployment procedure, having a centralized solution helps keep parity amongst the teams.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

As we covered earlier, Kubernetes doesnâ&#x20AC;&#x2122;t truly have the concept of a user account, but they allow for service accounts. Instead of passing your admin keys around to everyone who needs to deploy, youâ&#x20AC;&#x2122;d have your CD layer integrate with Kubernetes through a service account. From there, your tool can issue its own

set of user accounts and privileges. Keep this pattern in mind, as most other tools operate like this.

6.3 Integrating With Your Current Flow In your journey, try to keep the working pieces of your development flow. The most popular open-source and commercial tools involved in a development flow

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

typically integrate well with today's available CI/CD systems, but there are no guarantees. Every shop has its own requirements, so we cannot recommend one tool or SaaS offering over the next. As you look for ways to fill gaps, please keep the following in mind. At the bare minimum, your CI/CD solution should have the ability to: y integrate with your source code repository so that actions already in play can be used as triggers y build containers y push your containers to a container registry y run a testing harness y send notifications through existing communication channels y schedule a deployment to your container orchestrator Pro Tip: A CI/CD solution can be made from various components tied together through integration. Learn more about CI/CD integrations Here.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

7. Observability In the past, applications were either up or down. Systems engineers would implement basic health checks and there would be an alert when those checks were out of compliance. Today’s applications are much more complex. Microservices are spread across geographies, resources are elastic, and servers are ephemeral. As your team moves closer to a production release, they will need observability tools to maintain service level agreements.

Magalix can help you identify some of these issues using KubeAdvisor and KubeOptimizer Learn more.

7.1 Service Monitoring And Logging What is broken? Service monitoring begins with health checks. These are simple checks of a service’s state. “Is my API getting a 200 OK?” Expose your logs, which can help your team narrow down what the problem is as quickly as possible. With modern applications, service monitoring encounters a few limits. First, these types of checks are binary. Your application is either running or it isn’t. Today, THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

the cycling and shuffling of microservices are so commonplace that sometimes, applications are built to accommodate that kind of behavior. Triggering alerts every time a service or server goes down may not be the right thing to do. Secondly, you need to know what to monitor ahead of time. Knowing what thresholds equal normalcy must be understood beforehand in order to configure the monitors. Thirdly, things can still be broken without triggering an alarm. In these cases, we need something a bit more intelligent to help us track where any issues are coming from. Pro Tip: Although basic health-checks still have value, they only tell part of the story. Research advanced monitoring topics such as the RED method, USE method, and the Four Golden Signals.

7.2 Distributed Tracing Where’s the bottleneck? Not all issues can be detected with a health check. If service monitoring checks on the state of an individual microservice, distributed tracing monitors and records the time it takes for your microservices to respond to a request. What if all your monitors are healthy but a small part of your application is slow? In situations like these where requests can pass through several microservices, it can be difficult to pinpoint the root cause. Distributed tracing gives a different viewpoint into your application by providing time metrics for each microservice in play. “DoubleClick by Google found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load.” - Google Research When your mobile site is slow and information can't be found, 29% of smartphone users will immediately switch to another mobile site or app. Intermittent performance issues are one of the hardest production issues to troubleshoot. When you have tens, or even hundreds of microservice replicas all jumbled together in your orchestrator, honing in on a subset of troubled replicas can be time-consuming. Not only do you have to see which microservice is performing badly, but a deeper inspection is required to see if this is happening across all replicas of the same microservice, just a few of them, or only one.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Distributed tracing can help you narrow down the time it takes to identify where issues are by visualizing and comparing requests sent to the same endpoint. When distributed tracing is combined with service monitoring, you can start to answer questions about where non-trivial issues are stemming from. Although this pair provides great visibility into your application, we still need to answer why performance issues are happening.

7.3 Application Performance Monitoring Why is it slow? In 2012 Amazon calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. - FAST COMPANY 2012 was a long time ago- and Amazon made around $61 billion that year. In the THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

first quarter of 2020, their revenue surpassed $75 billion, so you can only imagine how much a slowdown will cost them today. Other studies describe massive drop-offs within the first few seconds of underperformance, such as this survey

published by Adobe. https://blogs.adobe.com A slow application might as well be a broken application. Completing the trifecta of observability is Application Performance Monitoring, or APM. APM helps software engineers understand why their microservice is having performance issues by instrumenting custom hooks into their code. These hooks can provide a number of interesting facts the software engineer is interested in. Sometimes itâ&#x20AC;&#x2122;s not obvious why the code isnâ&#x20AC;&#x2122;t performing. Depending on the different features your APM supports, the application performance monitor may tell you other pertinent pieces of information that could help you debug what's going on. This information might include the amount of resources used during a transaction or how long a particular function call takes. From a code perspective, APMs provide a granular view into the various factors that can contribute to performance degradation.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Observability is more than just knowing what’s up, what’s down, and catching an occasional glimpse of your logs. It’s diagnosing the internals of your application by checking on its output. Although APM is usually implemented by the software engineering team at the code level, the infrastructure to capture APM metrics are typically run by systems engineering teams. Operating with all hands on deck, all three observability tools combined with operational knowledge should minimize the time it takes to recover from a problem. Pro Tip: Turning on “everything” might be a bit too verbose for your needs. Try to capture only what you need to answer the most vital questions.

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

8. The Journey Continues... After your production release, your transformation will be complete, but your journey is far from over. Much like your application, your culture and your processes will need to adapt and evolve, improving with each iteration.

8.1 Continuously Improving In our three transformation stages, each stage was a precursor to the next. We started out conceptualizing our goals, and slowly built our way towards achieving them one step at a time. Things are no different now. As you set your sights on your next milestone, new challenges and problems will arise. Schedule time to address your issues while continuing to make small improvements. Conducting team syncs, one-to-one meetings, and retrospective sessions are good ways to discuss issues and discuss proposed changes out loud.

8.2 Sharing Your Story Sharing your story is a great way to reflect and assess all that has transpired. Spend some time reflecting on what went well, and what you would do differently next time. These insights may prove to be valuable in the near future. Once your teams have gained momentum, take the time to share with each other. All the search results and articles that helped with your journey wouldn’t be possible without our community continuously giving back. Stories inspire and motivate others to take on this challenge. Help others learn from your mistakes.

8.3 It Will Never Turn Out Exactly How You Think It Will Don’t expect things to change overnight. Taking on a new process while implementing new tech is hard but not impossible, as you have learned throughout this book. One of the biggest factors that will contribute to your success is how engaged you are with your teams. Out of all the times I’ve gone through this, the 34

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

most successful transformations occur when the different teams of the company are aligned with the organization's vision. Understanding your people well enough to implement just enough process and technology to get everything right is a balance that can only be achieved by knowing the weight of all of the components. You know your teams better than anyone. Work together, stay firm in your steps and challenge your teams to transform. The effort will be worth it at the end. Schedule a 20-minute demo with one of our experts

THE HITCHHIKER'S GUIDE TO THE CLOUD-NATIVE GALAXY

Thank You This book brought to you by Magalix team Smart, Always-on Kubernetes Guardrails. Enforce and scale Kubernetes best practices and standards. Get the right visibility at the right time. Do it as a team. Talk to Our Experts

team@magalix.com Magalix.com

MagalixCorp