If you haven\u2019t been paying attention to the world of enterprise IT infrastructure, you may have missed the sudden rise of Kubernetes to a position of absolute domination.<\/p>\n
It seems that containers themselves are still well behind the years, but at the Cloud Native Computing Foundation\u2019s KubeCon + CloudNativeCon<\/a> in Barcelona last month, it was patently obvious that containers are here to stay and Kubernetes has handily won the container orchestrator wars.<\/p>\n \n Such rapid dominance is unusual. Gray-hairs like me will recall the Internet protocol wars of the early nineties, as the battles among contenders like Netware and Token Ring dragged on for years before TCP\/IP finally won out.<\/p>\n And let us not forget the UNIX wars of the dot-com era, as vendors positioned one flavor over another until eventually the open source dark horse, Linux, surprisingly came to dominate.<\/p>\n The main reason TCP\/IP, Linux, and now Kubernetes won their respective battles is the fact that widespread agreement on foundational infrastructure technology is good for everyone. But business advantages of picking a winner don\u2019t explain the remarkable velocity that Kubernetes exhibited on the way to the container orchestrator brass ring.<\/p>\n We can attribute this rapid ascent, in fact, to a confluence of trends. Perhaps the most predictable of these is the maturation of the public cloud \u2013 not simply the market dominance of the big cloud players, but also the widespread acceptance and understanding of core cloud best practices, including horizontal scalability, resilience, and self-service configurability via declarative representations and APIs.<\/p>\n The second trend that contributed to Kubernetes\u2019 victory: DevOps. There are, in fact, two sides to DevOps: first, the organizational transformation as technical teams learn better ways to collaborate in order to deliver and run better software faster than previously possible.<\/p>\n The second: a broad set of tooling that automates many of the tasks that app dev and ops teams must conduct \u2013 tooling that itself participates in the same API-centric, declarative configurability that it inherits from the cloud.<\/p>\n Bridging the maturation of cloud best practice and the dual roles of DevOps is perhaps the most important trend of all: cloud-native architecture.<\/em> Cloud-native architecture builds on both cloud and DevOps best practices, taking them beyond the cloud itself to all of enterprise IT.<\/p>\n As it turns out, the best way to get started with cloud-native architecture happens to be implementing Kubernetes \u2013 although cloud-native covers the gamut from traditional virtualization to containers to serverless computing.<\/p>\n In fact, cloud-native is more than an architectural approach. It represents a lens through which we can see the entirety of enterprise IT in a new light. For this reason, I consider it to be a new architectural paradigm.<\/p>\n Cloud-native architecture didn\u2019t spring forth fully formed out of nothing, of course. Many architectural trends that came before helped teach us the lessons we needed to learn in order to make cloud-native a reality.<\/p>\n In the 2000s we deployed service-oriented architecture<\/em> (SOA), whose implementation typically depended on sophisticated middleware. These enterprise service buses (ESBs) handled a variety of tasks, including integration, routing, data transformation, security, and more, while exposing application functionality typically as Web Services.<\/p>\n SOA was therefore able to expose lightweight, language-independent service endpoints by shifting the intelligence to the middleware \u2013 a pattern we now like to call \u2018smart pipes, dumb endpoints.\u201d<\/p>\n With the rise of the cloud transforming the role and nature of middleware, coupled with the rise of containers and microservices, SOA eventually gave way to microservice architecture. <\/em><\/p>\n Unlike Web Services that were little more than \u2018dumb\u2019 XML-based endpoints, microservices are cohesive, parsimonious units of execution \u2013 little packages of goodness that only do one or two things, but do them well.<\/p>\n In common parlance, we refer to microservices architecture as \u2018smart endpoints, dumb pipes.\u2019 The microservices are their own mini-programs, with all the smarts we can cram into them. But to integrate them, we typically use nothing more intelligent than HTTP-based RESTful interactions or lightweight, open source queuing technology.<\/p>\n Replacing ESBs with \u2018dumb pipes\u2019 made sense in the context of the paradigm shift from SOA\u2019s on-premises context to the cloud-centric world of microservices architecture, but implementation, scalability, and agility challenges remained.<\/p>\n These shortcomings of microservice architecture provided the perfect breeding ground for Kubernetes. In the Kubernetes-fueled cloud native architecture paradigm, we have \u2018smart endpoints, smart service meshes<\/em>.\u2019<\/p>\n Service meshes introduce a new approach to integrating microservice endpoints that is entirely cloud-native. Service meshes like the open source Istio<\/a> (along with its counterpart, the Envoy<\/a> service proxy) also enable the discoverability and observability of containers and their microservices.<\/p>\n As a result, service meshes in conjunction with Kubernetes allow the full dynamic and ephemeral nature of containers to support core enterprise concerns of security, management, and integration \u2013 benefits of ESBs in the SOA days, now brought forward to a fully cloud-native architectural paradigm.<\/p>\n Ironically, the best way to understand the paradigm-shifting power of cloud-native architecture is to highlight what\u2019s absent from it: cloud-native is codeless, stateless, <\/em>and trustless.<\/em><\/p>\n I don\u2019t mean to say that we don\u2019t have to deal with state information or write code, and we can certainly trust some things. Rather, these three \u2018lesses\u2019 characterize core cloud-native principles.<\/p>\n By codeless I mean that Kubernetes is configurable<\/em> and extensible<\/em>, but there\u2019s no call for it being customizable<\/em>.<\/p>\n Operators handle configuration via YAML files (among other declarative techniques), giving vendors plenty of opportunity to build user-friendly configuration tooling. Even the various \u2018flavors\u2019 of Kubernetes \u2013 and there are several \u2013 all share a single code base.<\/p>\n Containers are also inherently stateless, a necessary side-effect of their inherent ephemerality. After all, you wouldn\u2019t want to store data in one if it could disappear at a moment\u2019s notice.<\/p>\n Kubernetes must handle state information \u2013 both persistent data in databases and file systems as well as more transient (but still persistent) application state in caches.<\/p>\n To accomplish such state management in a stateless environment, Kubernetes follows cloud-native architectural principles by abstracting storage via codeless principles and exposing such stateful resources via APIs. This approach allows for whatever availability and resilience the organization requires from its persistence tier without requiring the containers themselves to be stateful.<\/p>\n The third of the \u2018lesses\u2019 \u2013 trustlessness \u2013 is an essential characteristic of modern cybersecurity. We can no longer rely upon perimeter security to provide trusted environments. Instead, we must assume all parts of are network are untrusted, and every endpoint must establish its own trust.<\/p>\n You shouldn\u2019t be surprised that Kubernetes calls for trustless interactions. Microservice endpoints are dynamic, and service meshes abstract them \u2013 so it\u2019s essential for such abstracted endpoints to take care of their own security. Trustlessness, in fact, is one of the main reasons why service meshes are so important to cloud-native architectures.<\/p>\n Cloud-native architectures leverage cloud and DevOps best practices to deliver codeless, stateless, and trustless infrastructure that supports the full breadth of modern enterprise infrastructure requirements \u2013 and Kubernetes is at the center of the story. It\u2019s no wonder it has become the dominant central technology to the cloud-native architecture paradigm.<\/p>\n Infrastructure engineers should understand the importance of architecture to the Kubernetes story. Without it, the entire Kubernetes landscape has the appearance of a m\u00e9lange of miscellaneous projects and components.<\/p>\n IT and business executives need not concern themselves with the trees, but must certainly understand the forest that is cloud-native architecture. Enterprise IT is undergoing a top-to-bottom transformation, and leaders won\u2019t be able to understand the challenges of digital transformation unless they properly support the bedrock such transformation rests upon.<\/p>\n And for you architects, you\u2019re every bit as important as always, perhaps even more so. The challenge for you is coordinating all the architecture efforts in your organization. Cloud-native architecture is essentially infrastructure architecture, but application, solution, and enterprise architecture must all work together for your organization to achieve success with cloud-native architecture in today\u2019s digital era.<\/p>\n","protected":false},"excerpt":{"rendered":" If you haven’t been paying attention to the world of enterprise IT infrastructure, you may have missed the sudden rise of Kubernetes to a position of absolute domination. We can attribute this rapid ascent, in fact, to a confluence of trends. Perhaps the most predictable of these is the maturation of the public cloud. The second trend that contributed to Kubernetes’ victory: DevOps. Bridging the maturation of cloud best practice and the dual roles of DevOps is perhaps the most important trend of all: cloud-native architecture.<\/p>\n","protected":false},"author":396,"featured_media":3092,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[187],"tags":[94],"ppma_author":[2217],"class_list":["post-1777","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bigdata-cloud","tag-data-science"],"authors":[{"term_id":2217,"user_id":396,"is_guest":0,"slug":"jason-bloomberg","display_name":"Jason Bloomberg","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/?s=96&d=mm&r=g","user_url":"","last_name":"Bloomberg","first_name":"Jason","job_title":"","description":"Jason Bloomberg is the founder and President of Agile Digital Transformation analyst firm Intellyx<\/a>. A leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation, he is the author\/co-author of four books, including The Agile Architecture Revolution. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018<\/a> and #15 on Jax’s list of top DevOps influencers for 2017<\/a>, the only person to appear on both lists."}],"_links":{"self":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts\/1777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/users\/396"}],"replies":[{"embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/comments?post=1777"}],"version-history":[{"count":2,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts\/1777\/revisions"}],"predecessor-version":[{"id":29179,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts\/1777\/revisions\/29179"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/media\/3092"}],"wp:attachment":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/media?parent=1777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/categories?post=1777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/tags?post=1777"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=1777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}A Happy Convergence<\/h2>\n
Cloud-Native as New Architectural Paradigm<\/h2>\n
The Precursors to Cloud-Native Architecture<\/h2>\n
Cloud-Native Architecture: Beyond \u2018Smart Endpoints, Dumb Pipes\u2019<\/h2>\n
What Cloud-Native Architectures are Missing<\/h2>\n
Key Takeaways<\/h2>\n