Tag: cloud-native

  • Are We Delivering?

    Are We Delivering?

    I had an interesting conversation today where I was told, “We do great with CI but terrible at the CD part.” My immediate reaction was to point at all the great CD activity going on in vendor space right now. But as I stopped to ponder, I realized that we’re doing all of that great CD activity to play catch-up.

    DevSecOps has us covered in spades—the toolsets allow for scanning and protection all through the process, from the first line of code to application retirement. I would argue that after being left out in the cold, DevSecOps has done a better job than DevOps at the right side of the equation.

    In DevOps, the various “cloud-native” deployment models (I use scare quotes because they’re not really cloud-native. If you dig into them, nearly every one of them includes Kubernetes in their definition of cloud) are starting to do the job admirably, but in shops starting to automate the entirety of the process, the CI part has been automated and code delivery accelerated for a good long while.

    In short, adoption seems to prove, once again, that the benefits of rapid development are more important than the benefits of offering a stable, repeatable deployment environment. This makes one wonder what, exactly, we should be doing to convince IT and business leaders in orgs smaller than web monsters that security and repeatability both demand the implementation of capable continuous delivery.

    I think we failed the audience when we allowed pundits to blather on and on about deploying thousands of times a second when most applications in most orgs need to deliver at a significantly slower pace. And not only that, but want to deliver at that slower pace, given the “Don’t fix what isn’t broken” rule. Even if the environment is stable, rolling out for a single minor bug fix is possible but it’s not the best use of time—both computer and human.

    But we are catching up. We have things like GitOps and Kubernetes automation catching up with the rate of development; security is already there and test automation is ready to find issues before deployment. It is simply implementation that is behind and, as time goes on, more orgs will get the implementation part nailed.

    And through that process, you’ll be there, rocking it. Step up and make sure it is done right. The entire process is there; you could sleep better at night knowing that it is all in place and you are not likely to get a midnight call. Your org loves stability, you love good nights of sleep … Go out and get it.

  • Predict 2023: Stand and Deliver

    Predict 2023: Stand and Deliver

    It’s that time of year again—the New Year’s ritual: Time to predict the big trends in your world for the new year. By now you have probably seen dozens of headlines, articles, videos and interviews telling you what big trends will shape the coming year. Here at Techstrong Group, our Predict virtual event is built around this New Year’s ritual. This year, Predict is January 12, 2023 and, not to blow our own horn, but I think it is our best Predict event yet.

    What sets this event apart? Well, we have a real Techstrong Research team now headed up by Mike Rothman and Mitchell Ashley who are leading this year’s Predict event. We will have four tracks: DevOps, cybersecurity, cloud-native and digital transformation. Each track will kick off with either Mitchell or Mike presenting a Techstrong Research trends report for that market.

    After the trends report, there will be a keynote panel featuring some of the top thought leaders in each of these fields. This will be followed by other sessions that explore what this upcoming year has in store. Many of these sessions will be streamed live on January 12, 2023 and allow for audience questions and input.

    But wait—there’s more! One session I am really looking forward to features John Willis and Damon Edwards live at Techstrong Group Studios giving us their personal predictions for 2023. John and Damon need no introduction to the DevOps community. This should be a great session, so don’t miss it. I am also moderating two great panels; one is with C-level executives from CloudBees, JFrog and GitLab and Kohsuke Kawaguchi (KK), the creator of Jenkins and co-CEO of Launchable. The other panel features my friend Emmet Keefe of Insight Ignite who has his finger on the pulse of the digital transformation market.

    The best part? We’ll have a live chat available so you can interact with the speakers and network with your fellow attendees. And you can register and attend Predict 2023 for free. That’s right—this analyst-led, daylong virtual interactive event is free. Don’t wait! Head over right now and register here.

    Another highlight will be the announcement of our DevOps Dozen winners at the event. This year, the DevOps Dozen broke all of our previous records for both nominations and community votes. It has been quite a tough job selecting the winners from such incredible submissions and nominations.

    I haven’t even mentioned the amazing cybersecurity sessions hosted by Mike Rothman or the sessions covering the cloud-native vision with Mitchell Ashley and digital transformation with Mike Vizard. There is just so much great insight you won’t want to miss.

    A big thank you to all of the sponsors, panelists and speakers who help us make this event a true standout. If you want to get a head start on learning about big trends for 2023 and how they’ll impact cloud-native, cybersecurity, DevOps and digital transformation, check out these articles and register for Predict 2023 on January 12, 2023. We hope to see you there! 

     

  • Chronosphere Raises $115M in Additional Series C Funding at a $1.6 Billion Valuation

    Following a year of record growth, Chronosphere welcomes new investors GV (formerly Google Ventures) and Geodesic Capital as existing investors double down on company’s cloud-native observability platform 

    New York, NY, January 10, 2023 — Chronosphere, the only cloud-native observability platform that puts engineering organizations back in control by taming rampant data growth and cloud-native complexity, has raised an additional $115 million Series C funding. New investors include GV (formerly Google Ventures) and Geodesic Capital, bringing Chronosphere’s total funding to $343 million, and increasing the company’s valuation to $1.6 billion. Existing Chronosphere investors also participated in the round including: Addition, Founders Fund, General Atlantic, Greylock, Glynn Capital, and Lux Capital. The round will support continued innovation and go-to-market efforts for its market-leading cloud-native observability platform.

    The funding comes on the heels of a record year for Chronosphere. As of their most recent quarter, Chronosphere tripled its ARR and headcount, attained greater than 145% net revenue retention, retained 100% of its customers, and was named to Otta’s “ROCKET LIST 2022 – 100 of the fastest-growing companies to accelerate your career.”

    Chronosphere also chalked up key wins at Robinhood, Snap, Obsidian Security, and Astronomer who join Chronosphere’s growing list of enterprise customers that include DoorDash, Zillow, and Visa.

    “Chronosphere’s game-changing platform gives us the visibility and control to manage our observability data, especially with our unprecedented growth, ” said Ryan Sokol, VP of Engineering at DoorDash. In fact, customers that use Chronosphere’s cloud-native observability platform, which enables customers to transform their data based on the need, context, and utility to optimize costs, improve user experience, and solve problems faster. The average customer optimizes their data set by 48% for significant additional cost savings.

    DoorDash’s success is in line with results from a recent Total Economic Impact™(TEI) study, conducted by Forrester Consulting on behalf of Chronosphere. The study examined cost savings and business benefits enabled by Chronosphere, and found that customers using the company’s cloud-native observability platform returned on average $7.9 million in benefits over three years. During the same timeframe, companies on average also saw $4.9 million in cost savings for 165% return on investment, with an average payback period of less than six months.

    “In a cloud-native world where businesses are looking for both efficiency and effectiveness, there’s a dire need for organizations to get observability right,” said Sangeen Zeb, Partner at GV. “Chronosphere has cracked the code to tame the data deluge in complex environments and provides better tools that quickly sift through the most meaningful data for better customer experiences and business outcomes.”

    “This funding underscores the crucial market need for powerful cloud-native observability solutions to generate positive business outcomes–especially critical now as companies seek more efficient and effective ways to improve customer experiences,” said Chronosphere CEO and co-founder, Martin Mao. “We plan to use this latest investment to bring our forward-looking observability solution to the broader market as we continue to disrupt legacy solutions that provide too little, too late for too much cost.”

    About Chronosphere 

    Chronosphere is the only cloud-native observability platform that puts engineering organizations back in control by taming rampant data growth and cloud-native complexity while accelerating innovation. Faster alerts and issue resolution ensures responsive and reliable cloud-native workloads underlying the most valuable services at leading organizations like DoorDash, Robinhood, and Abnormal Security. Teams at organizations of all sizes trust Chronosphere to help them drive competitive advantage and world-class customer experiences while reducing engineering burnout and eliminating lock-in. Chronosphere is a remote-first company, backed by Geodesic Capital, GV, Glynn Capital, Greylock, Lux Capital, General Atlantic, Addition and Founders Fund. For more information, visit https://chronosphere.io or follow @chronosphereio.

  • 5 Best Practices for Implementing Cloud-Native DevOps

    5 Best Practices for Implementing Cloud-Native DevOps

    As the world transitions to cloud-native offerings as an industry norm, DevOps is gaining traction for its critical role in supporting more efficient IT infrastructure. DevOps is designed to boost collaboration and communication by streamlining the automation process to expedite the creation and deployment of applications. Implementing cloud-native DevOps requires organizations to make a massive cultural shift. Without this change, businesses are unlikely to be as competitive or fully utilize the innovations the cloud has to offer. 

    There’s always a risk in adopting new technology. Following are five best practices to accelerate your company’s implementation process and address potential challenges head-on.

    1. Think cloud, adopt the cloud.

    Optimize technology with a variety of tools tailored for the cloud. Understanding how technology works in the open source environment that cloud-native DevOps relies on is as essential to successfully managing the components as it is to selecting the right tool for you. Don’t get locked into using one tool. Instead, select the right tool for each task while remaining as cloud-agnostic as possible.  

    2. Implement a dynamic security strategy.

    Not considering security is one of the most common pitfalls organizations encounter when using emerging technology. Security must be built into cloud-native development workflows and thought processes and diligently monitored. If funds are available, appoint a chief security officer responsible for scrutinizing DevOps security in the cloud and creating playbooks for each alert triggered. Cybersecurity is becoming more complex due to the unpredictable nature of adversaries and the sheer volume of technologies involved in each solution. One way to start is with a bug bounty program that can bring hackers to your side of the court.

    3. Commit to ongoing training.

    Perform a self-audit and/or penetration testing to reveal weaknesses in company technology, procedures and people. Invest in training to effectively address any gaps in cloud skills. Providing development opportunities will also improve employee engagement and retention, which is a challenge for many employers. Make sure your employees give ongoing feedback to the training’s content, its maintenance and evolution.

    While it may be tempting only to emphasize new-hire training, the rapidly changing technology landscape requires training efforts be geared toward ongoing learning for the entire team. This investment will pay dividends, with DevOps and the cloud netting major long-term savings. To make training more efficient, it can be conducted remotely. Integrate and target training based on employees’ job functions,  but don’t forget about non-IT employees—they must also have a basic understanding of cloud and cloud-native.

    4. Once, twice, automate!

    Automation is critical to minimize software development life cycle friction and eliminate dependence on manual labor. Provisioning networks, infrastructure, application deployment and setup can be automated and versioned with infrastructure-as-code (IaC) tools (such as Terraform). There are also endless automation opportunities for containers, cloud computing, security, testing, monitoring and more. For instance, containers allow developers to compartmentalize applications to work on components without worrying about their potential impact in other areas–making it easier to construct consistent, tangle-free deployments. However, it may be challenging to manage multiple versions, requiring infrastructure and testing investment.

    5. Performance-test your tests.

    Automated testing will save developers time and reduce human errors. It’ll also allow developers to take advantage of doubling up on testing, making sure every change is stable and benchmarked. Test during the development stage and lay the groundwork for an effective CI process, especially if you roll out patches regularly. Automated testing is easier in a cloud-based system and isn’t dependent on sufficient hardware to make it run properly, allowing cloud hosts to scale up or down easily.

    Final Takeaways

    Cloud-native DevOps is revolutionizing the way applications are being built and managed, and it starts with how we perceive our challenges. Embracing DevOps culture enables organizations to leverage cloud and cloud-native solutions to create reliable services that are easily scalable. While it may look resource-intensive, cloud-native DevOps is becoming a business necessity.

  • Index Tracks Impressive Growth of API-First Startups

    Index Tracks Impressive Growth of API-First Startups

    APIs are the building blocks of modern software, and their use continues to grow around the globe. A full 89% of investment into APIs will increase or stay the same over the next 12 months, Postman’s 2022 State of the API report found. And the evolving API-first approach is ushering in many innovations and startups into the field. This trend is epitomized by the latest research from GGV Capital, which maintains an API-First Index of leading developer-first software companies.

    The API-First Index tracks API-first companies that have raised $50 million in funding or more. And as of Q3 2022, the number of businesses that met this threshold increased to over 60. Just in Q3 alone, $350 million in funding was raised by companies on the index, and, in total, the index represents over $14 billion in funding. Undoubtedly, interest and investment in this space are expanding and will continue to increase in the year ahead. It’s a good area to keep tabs on, as the emphasis on modularity impacts how software is pieced together.

    I recently met with Tiffany Luck, partner at GGV Capitol, who oversees the API-First Index. Below, we’ll explore the index a bit more and get Luck’s viewpoint on why these findings represent a unique moment for API-first technology and business models as a whole.

    The API-First Index

    The API-First Index focuses on companies that serve niche functionally through APIs; also known as API-as-a-product. The list includes an assortment of API-based tools from FinTech, communications, health care, commerce and other sectors.

    For example, Stripe is likely the most well-known API-as-a-product, as it is commonly integrated as a way for businesses to accept payments. There’s also MessageBird, an API for sending notifications across any channel. Other examples include Mapbox, an API for geolocation data, Mux, an API for creating live and on-demand video experiences, Nylas, which offers a popular email API and Alpaca, an API for stock and cryptocurrency trading and many others.

    Currently, the index doesn’t include the entire API platform landscape of tools, which ranges from areas like API management to testing, documentation, monitoring, design, security and observability. There are also middleware integration platforms to consider as well. With these included, the list of well-funded API-related toolsets would surely be even longer.

    Why the Excitement About API-First?

    The number of people deciding to build API-first companies is rapidly increasing. These API-based web components are interchangeable and represent the future of software development. “The world is going toward web and cloud components,” said Luck. The trend represents a global movement with much effort reflected in Europe, Asia and the U.S. Furthermore, API models seemed resilient throughout ongoing economic uncertainty and the patchy VC funding of 2022. “APIs are holding up very well compared to the broader VC landscape,” said Luck.

    So, why is there so much excitement around APIs? Well, people are looking for best-in-class structural blocks that can be used to build common features like geolocation, AI, weather, payments or specific CRM functions. Niche APIs can swiftly deliver particular features without the bulk of a large platform. Another reason is that they’re relatively sticky—API-based delivery models are efficient at building a self-service platform that expands over time, which is a very keen prospect to investors, said Luck.

    Unicorn APIs Solve Hard Problems

    In evaluating API-first companies, Luck looks for those offering B2B solutions to super-hard, shared problems. This equates to reusable functionality that is difficult to build, maintain and scale individually. Furthermore, the solution must solve a need that’s common across companies but that is not core to their products.

    For example, Luck has her eye on a few impressive API-first use cases. Stream, for example, powers in-app user-facing features. Knock offers solutions for handling notifications. But many of the top most-challenging areas include financial services, as this functionality is difficult to build from a regulatory and connectivity perspective. Examples include Pinwheel, which aggregates real-time income and employment data. Method API does something similar but for aggregating consumer debts.

    Luck described APIs as a “modern way of accessing what would otherwise be technically inaccessible.” We’re seeing this action unfold in open banking, as new standards around the globe now mandate that consumer financial data be programmatically accessible, often in the form of an API connection.

    Developer Experience: The New Competitive Advantage

    In a competitive market surging with powerful developer-facing tools, non-functional aspects such as developer experience (DX), security, performance and reliability are becoming more of a focus. According to Luck, developer experience is probably at the top of the pyramid as it represents a catch-all for many of the aforementioned traits. Specifically, developer tools with high-quality DX have excellent documentation and must maintain backward compatibility to avoid breaking changes on the consumer side. “Ultimately, what you’re implementing impacts that customer’s end customer. Customers want zero negative impact and zero disruption,” she said.

    The API-First Index is good for the industry as it helps educate the public on private investing rounds. And as discussion around it increases, it brings awareness and visibility to the benefits of building API-first.

  • Introduction to MACH Architecture

    Introduction to MACH Architecture

    In recent years, the need to construct end-to-end digital experiences has become increasingly important. But to deliver new features and services promptly, organizations must double down on agility and reusability. As part of this trend, applications have become increasingly modular, often constructed using pre-built microservices and integrating common SaaS to avoid reinventing the wheel.

    MACH is an architectural style that fits into these trends quite well. It stands for Microservices-based, API-first, Cloud-native, and Headless. The locus of the movement is The Mach Alliance, a group of API-first companies abiding by these principles. At the time of writing, MACH is gaining mindshare as more API-first companies enter the market and the appetite for cloud-native technology grows.

    I recently chatted with Gary Ballabio, VP of technology partnerships, Cloudinary, about the ongoing MACH trend. According to Ballabio, MACH delivers “best of breed” technologies that avoid the bloat of larger platforms. Yet, for software consumers, building in a MACH style will require stitching together individual components and orchestrating them effectively. Below, we’ll explore MACH and consider the benefits and drawbacks of utilizing tools that conform to this approach.

    What Is MACH?

    MACH is an emerging software architecture style adopted by a number of commerce and digital experience tools. To understand MACH a bit deeper, it’s necessary to understand the underlying concepts of microservices, API-first, cloud-native and headless. So, let’s first break apart these familiar terms:

    • Microservices: Unlike monolithic development, a microservices architecture organizes functionality into self-contained, specialized components. This improves reusability and allows for more frequent, targeted software updates.
    • API-first: API-first takes design-first one step further. It means putting the consumption model, the API, ahead of other concerns, like the application or UI. Web APIs have become ubiquitous for connecting a microservices ecosystem and exposing data and functionality to partners and public consumers.
    • Cloud-native: An umbrella term for projects purpose-built for the elasticity and scalability of the cloud.
    • Headless: Headless means separating the front end, or “head,” from the back end. By decoupling development this way, websites and apps are better equipped to cater to multiple platforms and devices.

    According to Ballabio, companies can leverage cloud-ready best-of-breed functionality by integrating tools that adopt MACH principles. Incorporating one single SaaS to fit a specialized need can also be considered an alternative to using large, comprehensive enterprise commerce suites like Salesforce, Adobe or SAP, said Ballabio.

    There are many examples of specialized SaaS services built in the MACH style. Some include Algolia for search and recommendations, Cloudinary for media management, Builder.io for mobile experiences, or Contentstack as a headless CMS. All these tools are members of The MACH Alliance, a group of over 70 vendors, partners, startups, systems integrators and other ambassadors dedicated to fostering the MACH approach. And although the emphasis has been on commerce and digital experiences, MACH is expanding beyond that scope to other areas.

    MACH technologies support a composable enterprise in which every component is pluggable, scalable, replaceable.

    Some readers may wonder, “How is this different than Jamstack (JavaScript, APIs and markdown)? In a way, MACH is similar to Jamstack, as both approaches aim for headless frontend experiences and a modular backend powered by APIs. But a key difference, said Ballabio, is that MACH doesn’t dictate the use of specific programming languages.

    Benefits and Drawbacks of MACH

    MACH combines many development trends we’re seeing in the software landscape. Digital applications are becoming more composable, cloud-first is rising, and headless models can deliver customization benefits. Yet, there are some potential drawbacks to introducing this style too. So, let’s weigh some of the positives and negatives of adopting MACH architecture.

    Benefits

    • Flexibility: The most significant benefit of MACH is the flexibility it offers, said Ballabio. “There’s value in being able to choose the services you want to use based on your own unique requirements.” Looping in a specific API-first tool for something like e-commerce, payments, CMS or email can enable a lot of customization.
    • Reduced waste: This can create less waste, too, as you create a leaner footprint by acquiring only what you need for each project, and freemium models enable consumers to pay for only what they use. This is helpful when you want a single component but don’t require the bells and whistles of a more holistic platform.
    • Best-of-breed: Niche API-first products are focused on doing one thing really well, and this particular focus can improve quality and agility. It also releases engineers from being at the whim of an extensive product’s development life cycle.
    • Developer-first: Lastly, most digital experiences share common functionalities that developers shouldn’t have to reinvent. MACH supports being developer-first, says Ballabio, which is an asset to companies investing in developer experience.

    Drawbacks

    • Increased maintenance: Consuming many third-party cloud services will inevitably bring new maintenance hurdles. These include tracking, monitoring and securing all integration points. It also requires responding to new version updates.
    • Stitching together: Naturally, when you add a cloud-based abstraction layer to the services you consume, the onus is on the consumer to then to stitch them together to make components talk to one another.
    • Startup costs: Due to the coordination between services, initial costs and engineering time could be more than implementing a holistic suite, admitted Ballabio. “But you get more long-term benefits,” he said.
    • Assistance may be required: Those unaccustomed to microservices development and API integration may need help. This may require the support of systems integrators or middleware to orchestrate connections.
    • Lack of standards: MACH is more of a general architecture rather than a standard specification. Thus, the precise technologies under the hood and the specific behaviors may differ from service to service.

    Future of MACH

    A recent MACH Alliance study found 79% of tech leaders plan to invest more in MACH technologies in the next year. Although the style has been primarily trending in Europe, Ballabio predicts the U.S. will soon pick it up. The MACH Alliance presents and advocates for an open and best-of-breed enterprise technology ecosystem.

    Along with the rise of composable architecture, the MACH approach is gaining interest among cloud-native leaders who see the advantage of assembling applications using pre-fabricated building blocks. MACH is especially a good fit for greenfield development, where the slate is clean to integrate new technology.

    MACH represents a new category of companies that are growing together. Ballabio remarks that he feels part of a movement, part of an industry—and, arguably, this movement can potentially disrupt larger commerce ecosystems.

    But although MACH gives a name to a face, most techies still aren’t aware of the acronym. While the concept may, for now, live in the domain of vendor-speak, Ballabio foresees it becoming a more common parlance for consumers and end developers.

  • Introduction to SPIFFE/SPIRE

    Introduction to SPIFFE/SPIRE

    For a long time, people have been logging into the apps they use via passwords or password managers. And many open standards and identity providers on the market continue to evolve how users authenticate and authorize with websites and applications. The issue is that the same problem exists for software services—when applications talk to applications, how do we prove the credibility of service-to-service connections?

    Enter SPIFFE and SPIRE. SPIFFE is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. Together, the projects create a standardized, secure way to identify software services and authenticate them. SPIFFE and SPIRE recently reached graduation status with the Cloud Native Computing Foundation (CNCF), solidifying the projects’ maturity as a top open-source standard mechanism to deliver cryptographic runtime identity for both cloud-native and legacy workloads.

    SPIFFE and SPIRE are already used across many major public deployments. Yet not all developers are familiar with their intricacies. Below, I’ll take a gander at both projects and how they operate to provide a bit more context. I also spoke with Evan Gilman, SPIFFE/SPIRE maintainer, to gather more insights on the history of the projects and their future goalposts.

    What is SPIFFE?

    The Secure Production Identity Framework For Everyone (SPIFFE) is a specification for workload identity. According to Gilman, the easiest way to think about SPIFFE is as a passport. Similar to how people are issued passports in a common shape with a barcode and standard information, SPIFFE dictates the standard methods to prove and validate the identity of a service. It’s like bringing the “Sign in with Google” experience to the software services themselves, he adds.

    There are three key components in SPIFFE. First, SPIFFE specifies that services shall identify themselves with what’s called a SPIFFE ID, which is defined as a URI in the format of spiffe://trust-domain-name/path. These IDs are then encoded into a SPIFFE Verifiable Identity Document or SVID. SVIDs aren’t so much a document type themselves — instead, they support either X.509 or JWT document types. Last but not least, SPIFFE specifies a workload API that issues and rotates these SVIDs, along with the keys needed to validate them.

    What is SPIRE?

    SPIRE is the code that implements the SPIFFE specification—you can think of it as a production-ready SPIFFE runtime environment. SPIRE, the “flagship SPIFFE implementation,” is a true end-to-end instantiation of SPIFFE that securely issues SVIDs, renews SVIDS and performs attestation, among other functions. If SPIFFE defines what a passport is, then SPIRE is the agency that issues the passports, said Gilman.

    The SPIRE agent runs on a node and exposes the workload API, which hooks into each workload. A workload, as defined by the SPIFFE documentation can be a web server, an instance of a MySQL database, a worker program or a web application composed of independently deployed systems. By communicating in this manner, SPIFFE/SPIRE can solve the issue of “secret zero,” which refers to the conundrum of proving the first credential to newfound systems.

    More Background on SPIFFE/SPIRE

    Joe Beda, a co-founder of Kubernetes, first proposed SPIFFE at GlueCon in 2016. At the time, Google was considering what internal technology it had that might prove helpful to the broader industry. It’s said that the technology that inspired SPIFFE/SPIRE can trace its roots to security and identity subsystems brought to Google from AT&T and Bell Labs.

    Nowadays, SPIFFE/SPIRE is actively maintained by many organizations, and we continue to see impressive production use cases. “SPIRE is deployed in some staggeringly large cases,” explained Gilman. SPIFFE/SPIRE adoption can be seen within GitHub, Netflix, Pinterest, Square, Transferwise, Uber and many other large technology companies. In terms of ownership, Gilman said that SPIRE is most used by platform engineers, infrastructure engineers or security engineers, depending on the organization’s roles.

    Future Outlook for SPIFFE and SPIRE

    SPIFFE/SPIRE appear to have the resources and backing to maintain a stable implementation, so the future looks bright for both projects. In terms of new features, in mid-2022, a first-class integration with SPIRE was merged into the Istio service mesh as a more flexible alternative to Istio’s built-in SPIFFE implementation. Another recent update is experimental support for SPIRE on Windows. Regarding future plans, SPIFFE/SPIRE maintainers will likely continue to iteratively improve the specification and implementation with frequent updates.

  • What’s Next for Cloud Computing? Distributed Cloud

    What’s Next for Cloud Computing? Distributed Cloud

    The public cloud has greatly advanced IT by allowing teams to interact with their data and write new applications in a cloud-native way. The cloud simplifies the application development process, provides services on demand and allows you to pay as you go. There has been phenomenal growth in public cloud use and all estimates show that it is likely to keep growing in the near future. 

    Nevertheless, most IT computing still takes place outside of the public cloud, simply because there has been no effective way to consume cloud-native services outside of data centers (or “regions”) operated by the hyperscale cloud providers. This location constraint negatively affects cloud computing in three main ways: Performance (latency, throughput), data sovereignty (residency, regulations) and commercial considerations (legacy architecture, pricing). 

    As a result, to realize the cloud’s fullest potential, many enterprises are turning to a recent innovation in cloud computing: Distributed clouds that are untethered to specific locations or regions.  

    How does this work? Through APIs, the distributed cloud connects to any IT stack in any location and provides cloud functionality as if running on a hyperscale cloud. However, instead of running in a dedicated location, it runs on existing infrastructure on top of any IaaS, virtualized environment or bare-metal machines. It is agnostic to the stack’s underlying physics and doesn’t require any installation or capex. It runs workloads in any environment: Commercial data center, on-premises facility, edge microcenter or even in a multi-facility hybrid environment. 

    How the Cloud is Transforming Enterprise and SMBs

    Modern application development lives and breathes cloud computing. It’s been the enabler for much of the recent progress with modern applications—such as those dedicated to IoT, smart cities and personal health, for example—and will continue to be the infrastructure on which enterprises and small businesses develop new innovations. But as more and more businesses employ a cloud-first approach using cloud-native architectures and technologies, “IT budget” has become synonymous with “cloud budget.” And this is often a very expensive proposition.

    Therefore, the next step for many businesses is to manage cloud computing costs while supporting legacy and cloud-native applications as well as cloud migration. Their computing strategy may be simultaneously on-premises, bare metal and hybrid across multiple continents. And so they need a cloud with architectural latitude to match their needs as well as their budget. 

    This flexibility is provided by the customizable distributed cloud. By facilitating interoperability with existing infrastructure, it enables enterprises to deploy and infinitely scale applications anywhere they need. The more openness they have in terms of where they run applications, the more freedom they have to optimize their budget. 

    Who is Driving Cloud Computing Innovation?

    Amazon, Microsoft and Google have gone from being the innovators in cloud computing to being the incumbents. Innovation in the cloud is coming from startups as well as legacy IT companies. Here are a few examples:

    • Kyndryl has emerged as one of the system integrators of choice when the Fortune 500 look to innovate and modernize their IT and application infrastructures. Kyndryl has been engaged by large companies to solve many of the challenges that cloud computing has created. One of the innovations they have championed is the distributed cloud.
    • NetApp has spent over $2 billion on more than a dozen acquisitions to build their cloud portfolio. Their focus has been on creating a portfolio that gives enterprises the ability to bridge their various compute and storage infrastructures to the cloud. As opposed to assuming that their customers will have greenfield implementations on cloud infrastructure, NetApp has built a portfolio that allows them to meet their clients where they currently are in terms of architecture and to shift from there into more cloud-native capabilities. 
    • Zenlayer has built cloud infrastructure in diverse geographies, giving them global reach that even the hyperscalers can’t rival. Zenlayer claims to provide cloud infrastructure that is so globally distributed that they are within 25 milliseconds of latency from 85% of the world’s internet population. This focus on physical infrastructure locations that enable global performance is an important innovation for many modern applications. 

    Emerging Cloud Computing Innovations

    The distributed cloud, which integrates programmatically into any existing local infrastructure, is an innovation that drives businesses forward by providing them with a cloud that can be customized for specific locality requirements. Without requiring any installation, its cloud-native building blocks leverage existing servers to run application workloads in any environment—private, public, on-premises and hybrid. 

    As a result, application owners are able to build an optimized cloud computing strategy, taking advantage of existing and available infrastructure in the location—or multiple locations—of their choosing.  

  • Optimizing Prometheus Implementations With Managed Services

    Optimizing Prometheus Implementations With Managed Services

    Prometheus is a leading metrics-based open source monitoring solution and time series database used across the IT community to collect metrics from systems, applications and services. According to the 2021 Cloud Native Survey from the Cloud Native Computing Foundation (CNCF), the use of Prometheus in production has reached 65%, an increase of 43% year-over-year.

    “As cloud-native stacks have grown and matured, observability has become crucial for visibility into application metrics, performance, alerting, and insights,” said Chris Aniszczyk, CTO of CNCF. “Prometheus is a key element of this, enabling organizations to build a foundation of observability.”

    If you are using Prometheus, it is probably because of its many advantages including reliability, easy initial implementation and its open source nature. However, in addition to these benefits, Prometheus also brings several challenges if you are deploying and maintaining the solution on your own.

    Facing the Four Main Prometheus Challenges

    Prometheus users face four primary challenges that can be alleviated by the right service provider:

    Challenge One: Support

    Prometheus users face the dilemma posed by any open source tool: There is no vendor behind the solution to deliver technical support. It is easy to take tech support for granted, but when you are working with a technology that is not supported, even a small issue can become a substantial problem. A commercially-backed product can provide a critical level of expertise you do not have in-house, and take on responsibility for keeping the system up and running.

    Challenge Two: Maintenance

    The greatest challenge you’ll likely face with Prometheus is the amount of time your team must spend configuring and maintaining the system. 

    Just one example of how Prometheus drains your resources is the use of third-party exporters to expose metrics in the Prometheus format. These integrations are designed by members of the open source community an do not come with any support; upgrades are hit-or-miss.

    Exporters are difficult to maintain. First, there are often multiple exporter options and choosing the right one for each of your services is time-consuming. Second, you can easily have hundreds of different services running in your environment and your team can spend hours every day making sure the exporters are working properly.  

    Another maintenance issue involves PromQL, the Prometheus query language. PromQL is a custom query language, and it is very complex and difficult to learn. Having to rely on your one PromQL expert for all Prometheus queries across the organization is simply not practical or sustainable.

    With all these maintenance requirements, you will have some team members spending all their time managing and maintaining a Prometheus environment, eating away at resources that could be used to focus on business needs and innovate new applications.

    Challenge Three: Scalability

    Users tend to deploy Prometheus in silos, with a separate server for each cluster. Over time, you may have tens or even hundreds of Prometheus servers in your environment that you are not aware of. This leads to scalability issues regarding consistency, maintainability and a global view of your metrics.

    In addition, storage is a major hindrance to scaling Prometheus, because the system typically stores metrics for about two weeks. If you need to analyze metrics older than a couple of weeks, you run into a serious problem. 

    Challenge Four: Correlating Data

    Data does not have much value if you cannot correlate it and, unfortunately, Prometheus does not provide correlation for metrics to other elements in your environment like processes or cloud regions. This makes it difficult to pinpoint the source or impact of a problem. 

    Options for Solving Prometheus Challenges

    Options are available to help you with Prometheus but most do not solve the four major issues outlined above. The following are your options:

    APM: APM vendors all have some level of support for Prometheus, but this is an add-on to their platform. They offer an ingest tool that can transform Prometheus data into a format you can query natively within the APM platform. In reality, they are not helping you utilize Prometheus but instead are forcing you to work within the constraints of their system.

    Cloud tools: Some cloud hyperscalers offer solutions to support Prometheus. These tools can help with deployment and infrastructure maintenance, but you are still stuck doing all the other configuration and maintenance work. 

    Managed service: The preferred option is a Prometheus managed service, which can alleviate all four of the main challenges posed by open source Prometheus. The right optimized managed service provider delivers support, maintenance, long-term storage and data correlation.

    Must-Have Capabilities for Your Prometheus Managed Service Provider

    The following are essential capabilities you should look for when choosing a Prometheus managed service provider:

    Prometheus compatibility: You need an optimized managed service provider whose platform is designed to be natively compatible with Prometheus, consuming data in the Prometheus format and allowing you to run PromQL queries on the data.

    Simplified PromQL: To eliminate the reliance on PromQL experts for every query, a managed service provider should simplify the use of PromQL, without breaking compatibility.

    Exporter management: The right optimized managed service provider will be able to streamline the selection, deployment and management of exporters, saving you a significant amount of time and effort.

    Automated discovery: Tracking and optimizing all your services can be challenging. For this reason, a Prometheus-managed service should be able to automatically discover the services running in your environment and help guide you with configuration.

    Metric Storage: One of the shortcomings of Prometheus is the lack of long-term storage. Consequently, a Prometheus managed service provider should provide a database for long-term storage of metrics, so you can perform comparative analyses of the data, from month to month and even year-to-year.

    Prometheus compatibility: If you already use open source Prometheus, your teams are used to using things like PromQL and Grafana dashboards. You should select a managed service provider that is Prometheus-compatible so your team can use the same dashboards and queries they have always used to view the data.  

    Conclusion: Optimized Valuable Tool

    Prometheus is not a standalone solution. But it is an optimized valuable tool to collect metrics for performance analysis and it is appreciated by your architects, developers and IT Ops pros. While Prometheus may have some limitations, it is worth finding a solution to these issues; that solution is a managed Prometheus service. The right managed service provider can give you the best of both worlds—all the benefits of Prometheus without the time, resources and expense needed to run it effectively.

  • Techstrong TV: Styra Declarative Authorization Service

    Techstrong TV: Styra Declarative Authorization Service

    Styra’s new launch of Styra Declarative Authorization Service (DAS) for Cloud-Native Entitlements. With this solution, IAM teams can move to cloud-native technologies while still using existing systems-of-record as well as scale to the level that their organization requires. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hello, everyone. Thanks for joining us on another TechStrong TV segment. Oh, I’m happy to have back on TechStrong TV today our friend, Tim Hinrichs, from Styra.

    Hey, Tim, welcome. How are you? 

    Tim Hinrichs: I’m doing great, Alan. Thanks for having me back on.

    Shimel: Yeah, it’s a pleasure to have you here. Tim, we always enjoy actually having the Styra folks on, whether it’s Bill, or you, or anyone else. Of course, Styra is a company that in the cloud native space has really kind of made a name for themselves. But though our audience is a cloud native audience and technical, they may or may not know Styra. They probably maybe have heard of Styra. They probably heard of OPA, but why don’t we kind of make sure everyone’s level set, Tim, and give them a little background?

    Hinrichs: For sure. Yeah, great. So, yeah, what Styra does is we help enterprises by providing them a unified solution to authorization. And so for folks that don’t know and don’t work on authorization every day like I do, just remember that authorization is this problem of controlling what actions that people and maybe software can take within a piece of software.

    So let me give you an example or two here. Every time I log onto my bank online, I can see all my bank accounts, but I may not be able to see my wife’s bank accounts. I may not be able to move money between her bank account and mine, and so that’s an authorization problem. It’s controlling what actions I can take. Can I withdraw money? Can I deposit money? So on and so forth. And so that’s one kind of authorization that we work on at Styra.

    But another good example is sort of at the developer level. So those websites that we all use every day, those are built by developers and developers are also taking action. And so one kind of action that they might want to take is they’re upgrading the software, or they’re deploying a database, or they’re changing some network configurations. Again, all of those are actions and there needs to be authorization controls in place to make sure that the right actions are being taken by the right people at the right time.

    And at Styra, we provide software that helps an organization sort of manage all of those permissions, all of those authorization policies across all those different kinds of decent software.

    Shimel: Excellent. Love it. And we might as well get it out of the way while we’re here, Tim. People who want to get more information on Styra, it’s Styra, S-T-Y-R-A, and it’s styra.com, correct?

    Hinrichs: Absolutely, yeah. Definitely check that one out.

    Shimel: Cool. All right, we’ve gotten that. Oh, you know what else, Tim? We didn’t even tell them about what your position at Styra is. We should give them that, too.

    Hinrichs: For sure, yeah. So my name’s Tim Hinrichs. I’m the CTO and co-founder at Styra and I spend part of my time working on our commercial product offerings, but then I spend the other part of my time on our open source efforts. And one of the things that we do in open source is we started the Open Policy Agent project, or OPA, as we like to call it, and then we donate it to the CNCF. So I’ve got a foot in both of those areas of work.

    Shimel: Love it. Hey, Tim, are you gonna be out at KubeCon in Spain in May, or planning it, not sure yet?

    Hinrichs: Not sure yet, but yeah, it would be great. I’d love to get back out, and start going back on that conference circuit, and seeing people, chatting with them about policy and authorization, and just seeing folks, again. I think it would be great.

    Shimel: We are currently planning on being there. We’re going to hopefully try to do some videos but a different sort of setup. I forgot what they’re calling it, something topist talks or something, so short, little, smaller segments. Again, assuming the world is right, we’ll be there.

    Anyway, but Tim, let’s focus in on what we want to talk about today, which is you guys recently announced a new offering. Tell us.

    Hinrichs: Yeah, for sure. So the new offering that we just released a little while ago, we call it the Entitlements Offering as part of our normal product called the Declarative Authorization Service. And so the idea behind this new offering is that it’s really designed to help organizations take custom applications and migrate them from on-premise data centers into the cloud more effectively, more quickly.

    And so the problem we kind of saw happening over and over was that if you’ve got one of these on-prem applications, especially an application that’s focused around helping your employees interact with each other or the organization as a whole, these employee-focused applications, a lot of those apps are dependent on what folks will call an on-premise entitlement service. So that entitlement service is often backed by LDAP, or Active Directory, or something, and it’s sort of just those applications sort of need to know which groups that employees are a member of in order to sort of grant permissions within the application.

    And so the challenge when you’re mind reading those kinds of applications into the cloud is that the cloud, what you don’t want to be doing is having an application running on the other side of the world and having to make a request all the way back to your on-premise LDAP or AD. The roundtrip time, the availability, the performance and availability, are just too poor. It’s sort of an anti-pattern in the cloud. And so these folks that we’re talking to are struggling because they want to migrate these applications in the cloud, but in order to do that, they also have to migrate those on-prem entitlement services to the cloud.

    And so this new offering from Styra really makes that easy. You sort of just hook it up to your LDAP or AD and then you can deploy that thing in as many cloud regions as you like.

    Shimel: Excellent, excellent. Back at the end of last year, I told our team here and I think we said it on our predictive that I thought IAM was going to be the battleground, the most important thing for us to be focusing on, especially as it relates to cloud native, and security, and stuff like this. Of course, this was before the software supply chain builder management, and the ransomware, and a lot of the stuff that we’ve seen come down.

    But I still believe that IAM is the kind of the soft, white underbelly. It’s where cloud security gets down in a lot of ways, right? You have cloud providers who are investing billions, literally billions of dollars, into their infrastructure and their security, and we count on them to deliver the security to a certain level of that stack. The rest of that stack, through a good chunk of it, is protected by our IAM.

    I mean, I’m not blaming anyone, but just this week, we’ve seen Okta with a problem, and I’m not blaming Okta. Any one of us can be the next Okta, or the next Solar Winds, or the next take your pick. We’re all vulnerable, at some point. But it goes to show you how vulnerable we really are through the IAM stuff.

    Tim, what made you guys kind of go down this path? I mean, obviously with what you do, it was kind of adjacent and it wasn’t out of left field, but what made you say, hey, we need to do this?

    Hinrichs: Yeah, there are a couple of things. You mentioned a whole bunch of things and one in which I want to respond to before I get to your question.

    Shimel: I’m sorry.

    Hinrichs: I think that the recent stuff around Okta was interesting because I think one of the things that should remind all of us of is just this idea that there are two kinds of companies in the world, those that have been compromised and those that don’t know they’ve been compromised, to your point.

    Shimel: Exactly, yeah.

    Hinrichs: And so this thing with Okta just I can highlight this idea that once you sort of understand and sort of internalize this idea that you’re gonna be compromised, the only sort of thing you can do is put defensive in depth in place. And so authentication, proving that you are who you say you are, which single sign-on vendors have done a tremendously good job of, is that first level of defense. But then authorization is that second level where what you want to do is sort of control the amount of damage that is done once one of those user accounts is compromised and that’s the notion of authorization. You limit the amount of permissions that every one of those accounts have.

    And so that’s, to your point, one of the foundational principles of security, that you layer levels of security in place so that when any one of them gets compromised, you have several others to put in place.

    Shimel: Absolutely. We hear the term zero trust getting thrown around and it’s funny, with zero trust, to a lot of people’s idea, I do my single sign on, so now I know Tim is Tim. And now, Tim, here’s the keys to the castle. Have at it. But I think what people miss is with zero trust, is just because Tim is Tim, Tim doesn’t get the keys to the castle. Tim should get just what Tim needs, not what Tim may want. He doesn’t get everything. So if Tim is compromised, I still limited my exposure.

    And, again, to me, that’s really when we start getting into the permutations of zero trust and how we do IAM, it’s so important that we have that. Not everybody’s access is created equal.

    Hinrichs: Right. I totally agree and I think, well, one of the more interesting things that we’ve seen is that part of why I think a lot of folks end up with maybe more permissions than they need is just that these authorization systems today traditionally have been hard to use. Every product, every project, every service on the planet has a unique way of solving authorization.

    So if somebody needs additional permissions for some small period of time and I’m the admin, well, I’ve got to go poke around and figure out how to give them additional permissions and then there’s this back and forth. “Okay, I gave you more permissions. Did that work? No, okay, I’ll give you more permission. Did that work? No.” And at some point, you just say, “Forget it, you’re an admin.”

    [Crosstalk]

    Shimel: You know what? I’ll give you everything.

    Hinrichs: “You’re an admin.” And then what happens is you’re supposed to pull those permissions back a week later, but then you forget because you get busy. And so I think there’s this very real notion of permissions creep where people just have more and more permissions over time. Because everybody’s definitely gonna ask for more permissions when they need them to do their job. Very few people are gonna say, “Oh, you know what? I’ve got too many. I don’t need those, anymore.”

    And so I think one of the things that we do at Styra, by trying to provide a unified solution, a foundational solution for authorization, is help with this. Because we say, look, there’s one collection of tools and technologies you need to learn in order to deal with permissions. If you can apply those to all your 57 different products and services, well, you just are more conversant with being able to give rights correctly and being able to revoke them. And so I think that speaks well to why in part we’re doing what we’re doing at Styra.

    Shimel: Absolutely. So if you don’t mind, Tim, let’s talk a little bit about kind of the business aspect of this new offering. How’s it packaged? How’s it offered? How’s it priced? Is there a free open source version, that kind of thing?

    Hinrichs: Yeah, and maybe I’ll also offer the answer to the question about why did we end up doing this ’cause I didn’t get to that.

    Shimel: Yeah, please.

    Hinrichs: Yeah, so it’s one of these nice things that because we have an active user base in the open source world and because we have active customers on the commercial world, we can just watch what they do all the time and then when we see a pattern emerge where we see the same people having to address the same kinds of authorization problems, then we realize, well, that’s a systemic problem throughout our community and organizations. And so then we can go ahead and put the energy into building a new offering, and that was exactly what happened with this entitlements solution.

    We just saw a number of our open source and commercial customers and users having to solve this problem and using OPA and DAS to do that. And so then we just realized, well, hey, if they’re kind of piece-mealing things together, why don’t we just put forth a real offering around this design specifically to solve this entitlements problem. So that’s how it came about.

    To answer your second question, how’s it packaged, and priced, and all that good stuff. Well, so typically what we do is this is another feature, so to speak, or a solution, or sometimes we call it a use case, for our product, our declarative authorization service. So that declarative authorization service was designed to provide a unified solution to authorization. It helps you with Kubernetes authorization, with microservice authorization service mesh. It helps you with public cloud through terraform, and now entitlements. And so in that sense, it’s yet another feature, so to speak, in the product that exists.

    And so in that sense, if you’re just using DAS, then you can kind of just pick that out of a list and put it in place. DAS is available as a SAS offering so everybody can run it and you can sign up for free, as well, so I definitely suggest if you want to try it out, go log in and do that. We do, for the enterprise version, also offer an on-prem solution. And so if folks want to actually run DAS on prem, it doesn’t have to be on prem. It could be in their private cloud accounts, then they can do that, as well.

    Shimel: Excellent. Once again, proving the old axiom, it’s not a product, it’s a feature, and it’s good when you can have a product, whether people can’t decide, well, it’s a platform, not a product, but you have a product that has multiple features like that that handle this kind of thing.

    Tim, it’s available now? So I assume it’s been beta tested, hardened, gotten the feedback, and it’s ready to rock and roll.

    Hinrichs: Yeah, it’s one of our earlier releases, for sure, but yeah, we definitely want people out there trying it and giving us feedback, for sure.

    Shimel: How do people go sign up and give it a whirl?

    Hinrichs: Yeah, just go to styra.com. There’s a signup link, and then when it drops you into the product, you’ll get to pick from one of several quick starts that help you sort of walk through putting stuff in place, and you can kind of kick the tires.

    Shimel: I love it. Tim, thanks for coming on and telling us about this exciting new feature in the Styra product line. Looking forward to hearing more. I do hope we get to see you at KubeCon in May in Valencia, hopefully, fingers crossed.

    Hinrichs: That would be absolutely fantastic, and thanks. It’s been a pleasure chatting with you, again, Alan.

    Shimel: All right. Say hello to all our friends at Styra. Tim Hinrichs, CTO co-founder at Styra here on TechStrong TV. We’re gonna take a break. We’ll be right back.