As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Amazon Prime Video has ditched its use of microservices-cum-serverless, reverting to a traditional, monolithic architecture. It vastly improved the workload’s cost and scalability. (more…)
Shifting from monolithic application development
Businesses need agility to deliver better services, meet changing requirements, and seize new opportunities as they arise. At the heart of many efforts are applications based on modern development strategies and techniques. Specifically, many businesses are moving away from monolithic applications of the past that are hard to modify and take a long time to bring to market.
Why the shift and why now? Over 80% of organizations expect to compete mainly based on customer experience (CX). As a result, businesses in the most competitive markets like retail, banking, insurance, financial services, and travel/hospitality cannot afford to wait months or years to release new services, applications, or features.
The bottom line is that software development teams are under pressure to deliver more of everything (new applications, enhanced features, more access options) in shorter time frames. A widely cited past industry study put the issues into perspective. Leading companies routinely perform multiple deployments daily. By comparison, low performers reported deploying only once a month at best. (At the extreme end of the spectrum, companies like Amazon and Google do deployments thousands of times a day.)
Monolithic application development does not work in this fast-paced environment. A simple change in an existing application, such as incorporating a new dataset, adding new features in a front-end app, or using a different analytics method, requires that the entire application be revised, retested, and redeployed. That all takes time. Lots of time.
A better approach is to use modern applications development methodologies. In particular, there is a shift underway to using cloud-native architectures based on loosely connected microservices and elements.
A cloud-native approach is particularly well-suited for modern applications for several reasons. For example, a cloud-native approach helps organizations address the customer experience drivers that require constant updates and new services. Each component of a cloud-native application can be deployed and maintained as a self-contained microservice. If any element of a broad application needs to be updated or changed, only that element needs to be touched. The rest of the conglomerate application remains the same.
z/OS plays well with cloud-native
Many industries under the greatest pressure to speed development and deliver ever-more customized, personalized customer experiences use z/OS systems. As noted, these are retail, banking, insurance, financial services, and travel/hospitality. Government also can be added to the list. It is a large user of z/OS systems and is constantly trying to improve access to its services via new or improved web, mobile, chat, social, and phone applications.
There are two ways to enhance and develop applications for these systems that use modern development methods. One is to make data, applications, and services that run on z/OS systems available as APIs and as microservices to be used by larger cloud-native applications.
The other method that is gaining more favor is to provide the modern development tools for the z/OS systems themselves. Specifically, modern application development approaches that move away from monolithic architectures need certain essential elements. Many rely on open-source development techniques, workflow automation, and continuous integration and continuous delivery (CI/CD) tools.
Bringing such commonly used tools to the z/OS environment helps businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.
In an age when it is getting harder to find developers with expertise in native z/OS programming, bringing familiar DevOps tools to the z/OS environment offers several benefits. Those who have the native z/OS skills can focus on core applications and leave the tasks like supporting a new front end or enhancing a web interface to others. After all, there are many more developers available with modern development skills.
Bringing the DevOps tools into the z/OS environment also lets businesses retain all the pluses of those systems. Namely, businesses are assured that the same reliability, superior performance, tightly controlled security, and massive scalability are retained and can be leveraged with integrated with a broader cloud-native application.
With microservices projected to grow globally at a 22.5% rate between 2019 and 2025, the choice between monolithic and microservices architectures needs to be carefully considered. If you are wondering what microservices are best suited for, or whether your business should stick to monolithic or switch to microservices, here are a few cardinal points to take into consideration.
A monolithic application is built on a single code base with a variable number of modules. The number of modules depends on the complexity of the business and its technical features. The whole application—and dependencies, when applicable—are built on a single system with a single executable binary for deployment.
A monolithic architecture has distinct advantages and disadvantages that should be evaluated when deciding when selecting the optimal type of architecture for the application.
Monolithic architecture pros:
Monolithic architecture cons:
Microservices architecture is designed to accommodate the need for large application development by providing a suite of modular components and services.
When considering what microservices are particularly well-suited for, the following advantages and disadvantages should be taken into account:
Microservices pros:
Microservices cons:
As microservices architecture provides a better way to manage growing data sets, leverage cloud storage and automation and deploy solutions fast, microservices are usually preferable to monoliths. However, they might not always be the best choice for an organization. Before opting for microservices, a careful examination of your company culture and business objective is imperative.
Sysdig and IBM announced they have extended their alliance to make Sysdig monitoring tools more broadly available across IBM public cloud services.
IBM first adopted the Sysdig platform to enable DevOps teams to monitor workloads running on a subset of the IBM Cloud in June 2018. Now the company will extend those managed instances of the Sysdig monitoring platform running on its own public cloud to include additional cloud services such as IBM Watson, Event Streams, Cloud Databases, Cloud Object Storage and Cloud Foundry.
Janet Matsuda, chief marketing officer for Sysdig, said monitoring capabilities as especially critical as the number of microservices-based applications running on public clouds continues to increase. IBM also makes use of the open source Prometheus monitoring platform to monitor many of those applications. Sysdig last month announced compatibility with Prometheus as a data source.
In the wake of the COVID-19 pandemic, it’s probable that more monolithic applications will also be moving into the cloud as part of organizations’ business continuity strategies. Applications that run in the cloud are easier to manage remotely. Regardless of whether applications are monolithic or based on microservices, it’s clear IT teams will be “flying blind” unless they have access to monitoring tools, Matsuda noted.
Over time, many of the monolithic applications being moved into the cloud will be transformed into a more flexible set of microservices that are easier to update. As that transition occurs, the need to observe the myriad microservices running on a public cloud becomes an even bigger challenge for IT teams.
Of course, some IT teams will prefer to employ their own monitoring tools versus relying on a managed service, especially if they are trying to centralize the management of IT across multiple public clouds and on-premises IT environments. However, for now, at least, the bulk of IT teams are still employing various public clouds in isolation from one another.
Longer-term, the relationship between Prometheus and commercial monitoring platforms is still being defined. Many application developers are relying on Prometheus to observe applications during the development process. Many IT teams, however, are already making extensive use of commercial monitoring platforms to identify and correlate issues in production environments. Sysdig is betting most of those organizations will continue to rely on those tools because they are easier to set up and navigate. In addition, each instance of a Kubernetes cluster currently requires its own instance of Prometheus.
On the plus side, the amount of time and effort being applied to instrumentation and observability as part of any set of best DevOps practices continues to increase sharply. Furthermore, the need to combine security and operational IT metrics and analytics to advance DevSecOps adoption is also going to push IT organizations toward more robust monitoring platforms. Arguably, the real challenge is no longer finding a way to instrument applications as much as it will be turning all the data being collected into actionable intelligence that can be relied on to automate the management of IT at an unprecedented scale.
Service Oriented Architecture (SOA) was the great hope of organizations decades ago when they sought to advance legacy system integration, reduce and bypass layers, and rapidly access the system of record. At the time, the existing solution was point-to-point integration, creating a brittle “spaghetti” middle layer that was hard to manage. This was replaced by SOA, which was later augmented with ESB. This fixed the spaghetti mess by creating an intermediate set of layers, which added complexity to the integration process.
Unfortunately, most IT departments with legacy systems and SOA still struggle to be as agile as needed in this ever-increasing global and digitized world.
Today, upward of 90% of the world’s enterprise applications are monolithic. When they were created, monolithic design was the best approach available. However, as business needs evolved and the demand for greater agility intensified, developers and IT teams are considering breaking free of these monolithic architectures.
SOAs have become a hindrance, not the solution they once were.
The promise of SOA initiatives was extending the reach of core business functions while reducing the internal expenses and complexity that grew alongside monoliths. SOAs achieved these goals by breaking the core functions of a monolith into web services using protocols such as simple object access protocol (SOAP) and eXtensible markup language (XML).
SOAP was built for universal application communications. Because it’s based on XML, SOAs designed with SOAP could, in theory, be used to create an agnostic integration layer. Rather than struggling to piece together various proprietary systems, these protocols would open monoliths on different operating systems so they could work together.
This agnostic integration layer would let system administrators connect pieces of a monolith to an enterprise service bus (ESB) to achieve an agile, plug-and-play SOA. In some cases, this approach succeeded.
A great deal of “legacy SOA” still provides value. In these cases, the value the SOA provides is the behind-the-scenes server-to-server communication that mostly aids developers. When it comes to serving internal and external customers–and their rapidly changing demands–SOA isn’t always up to the task.
To achieve service integration, the ESB must oversee the messages from start to destination. This communication isn’t as simple as the SOA vendors may have promised. Consider an SOA integration within a core banking application. The message must go from the core application on the mainframe to a branch office server. If the business logic states a message is only relevant for one business day, administrators must decide whether to move it to a queue, log or disregard when the day passes. This is a common scenario for core banking applications in an SOA, but how well does it work?
In this example–and others like it–the ESB must know whether a business day has passed to make the right decision about where to send the message. Therefore, the integration requires an algorithm–meaning that ESB cannot simply rely on a universal rule for sending messages between the monolith and external integration.
When administrators introduce new business logic into the monolith integration, it turns what was supposed to be an agnostic service layer into a new application layer, increasing complexity. Instead of simply integrating the monolith into a new digital service, the enterprise ends up with a larger monolith–one that includes the mainframe and all the new integration stacks.
Despite the promises of SOA, the integration problems result in increased maintenance time, greater complexity of code and software and the continued growth (not elimination) of monolithic applications.
The first rule of effective integration is “smart end-points and dumb pipes.” Building logic and layers into the service layer breaks that rule, increases the overall complexity and adds another legacy application to your portfolio.
Bottom line: Trying to optimize the SOA approach will only result in larger monoliths.
Using microservice architectures helps realize the original promise of SOAs, delivering the benefits of SOAs while removing many disadvantages.
For decades, CIOs have tried to transition away from monoliths by taking traditional approaches to integration, only to find they’ve doubled down on legacy investments. All these integration stacks end up coupled to legacy systems and only result in more work for the IT team–and a less agile organization.
The integration step of SOA was never intended to include business logic. Trying to force business logic into this approach leads to workarounds and extra effort just to achieve a less-than-ideal result.
The key factor is how to incorporate microservices without adverse effects. Luckily, microservices architecture can be forged from SOAs by introducing these new principles:
Ultimately, the goal should be to refactor monoliths in a way that shifts the IT stack toward microservices. By taking the right approach, you can make the most of both microservices and APIs within your SOA. You enhance your digital journey, leading you to IT efficiency, faster cycles, greater scalability and competitive differentiation.
As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the first in our weeklong series of the Best of 2019.
Microservices are moving to the mainstream. The IDC FutureScape: Worldwide IT Industry 2019 Predictions states that by 2022, 90% of all new apps will feature microservices architecture that “improve the ability to design, debug, update and leverage third-party code.”
With so many organizations adopting or about to adopt microservices, they must be doing something right. In fact, just considering the model is a positive step toward delivering quality software, faster. However, many companies are leaving microservices benefits on the table because there are many pitfalls on the road to success. It’s about so much more than just a technology choice and starting to code microservices.
Indeed, breaking your apps into microservices isn’t enough—you have to manage them, orchestrate them and deal with the data they create and modify. Before you even touch the keyboard it’s a good idea to think about a few points of strategy to ensure success.
Here are five microservices worst practices and how to turn them around.
You can’t take Calculus II without taking Calculus I. Similarly, you can’t roll out microservices without the proper prerequisites. To fully leverage microservices, companies must consider modularity and domain boundaries, and the fundamental distributed systems theory should be considered and established. In addition, while each service is independent, there are operational requirements that must be met. These include DevOps; PaaS; containers or immutable VMs; service replication, registry and discovery; and proactive monitoring and alerts.
The biggest mistake organizations make when moving to a microservices architecture model is underestimating how it’s changing the way they need to think about applications and especially the way they think about the teams developing those applications. Traditionally, there are many people involved in the development of an application, with each coming at it from his or her own perspective—the UI specialist, the middleware specialist, DBAs, sysadmins and so on. What worked for one might not work for the other when it gets thrown over the wall, and it often takes a lot of time and frustration to make everything work for everyone. Trying to do microservices without changing that model and mindset will almost certainly set your team up for failure. Instead, think in terms of cohesive, cross-functional teams, each fully responsible for its own unique services and its own set of customers for those services. Each team’s working with other teams as if it’s a business-to-business (B2B) relationship. It’s not an easy cultural transition, but it’s one that is essential for microservices to work.
An organization that goes all-in on microservices all at once is almost certain to run into problems that could completely derail the initiative altogether. Pick a small project, and staff it with people who see the potential of microservices and are excited to work with the technology. Once that project has been successfully completed, use it as a proof point to promote the further use of microservices across the organization and to get others on board.
Organizations are right to question the performance impact that microservices will have when migrating an existing monolithic application to a microservices model. But their concerns—and expectations—are often misplaced. Yes, there can be a performance hit when decomposing existing monolithic applications in favor of microservices. But what organizations need to understand is the goal of microservices is deployment speed over API invocation speed.
Isolating the development of a service within a team (as mentioned earlier) means the service can be updated as needed—whether that’s weekly, daily or even hourly—in response to business, competitive and security demands. In its Worldwide IT Industry 2019 Predictions report, IDC notes it is “already seeing enterprises that have shifted fully to these new approaches (and supporting tools and technologies) that dramatically accelerate their ability to push out digital innovation through their organization at 50-100 times (or more) the frequency of their traditional approaches.”
This worst practice is linked closely to the previous one. Organizations that pick the wrong applications to split into microservices or decompose an entire monolith without thinking about which parts might be best as microservices (and which would fail miserably as microservices) will have the odds stacked against them from the get-go. A financial application or a high-volume application that makes multiple calls may not be good candidates for microservices. Or, it may be that parts of these applications would work well in the microservices model even if the monolith as a whole doesn’t. The idea is to examine each legacy application carefully and to build new applications with microservices in mind from the beginning.
If you’re thinking that it takes a lot to establish a microservices foundation, you’re right. It’s a big investment, and it may take some time before there is a return on that investment. But organizations that move toward microservices in a thoughtful, purposeful way—exploiting the best practices of those that have gone before them—will likely find themselves more agile, more secure and more competitive.
Breaking monolithic applications into independently scalable services is the core of the cloud-native application model. By making cloud-native apps easy to deploy and manage, Kubernetes has contributed to a big change in IT practices.
Initial cloud-native conquests started with stateless services and quickly grew to encompass applications that manage data. Database management systems have long relied on centralized servers, but cloud-native architectures are now reaching even the largest monoliths. Among the most interesting cloud-native converts are analytic databases, which hold data arranged in storage formats optimized for extremely fast analytic queries over billions ,or even trillions, of rows.
The transformation of databases to cloud-native models has profound implications for data-driven applications. Intersecting trends in analytic database architecture and Kubernetes promise substantial benefits to the users of such applications as well as companies that operate them.
Over the last decade the quantity of data that businesses generate has decoupled from the size of the business itself. Ad networks, website analytics and service observability applications often ingest 1 million events per second (or far more) and may have tables running into trillions of records. Businesses need to analyze this information rapidly–for example, to diagnose faults in cloud applications or to retrain models for displaying online ads. Flexible, real-time analytics have gone from nice-to-have to business critical.
Meanwhile, new analytic engines have emerged that eliminate dependencies on specialized hardware and complex networking required by legacy data warehouses. Druid, ClickHouse or Elasticsearch run on commodity hardware and depend on basic compute, network and storage. Everything else, such as high availability (HA), is built into the application. Newer analytic databases offer built-in horizontal scaling using fleets of server processes. The server processes themselves typically run well in containers.
With these changes, analytic databases are increasingly cloud-friendly if not cloud-native. It is a short hop to deployment on Kubernetes.
At the same time, as analytic databases have shifted their operational model, Kubernetes itself has become more welcoming for databases.
One particularly important innovation for the database is custom resource definitions, or CRDs, which extend the Kubernetes API to define new types of manageable resources. Using CRDs makes it possible to have a single definition that shows the desired state of a complex application such as a data warehouse.
Another addition is Kubernetes operators, which manage custom resource definitions. Operators track custom resource definitions and take actions when they change. They can also track other information that might be relevant to managing the custom resource, such as changes to pods, storage or even related cloud-native applications. It’s like having a human operator who is constantly watching the application, except the rules are programmed into software that runs inside Kubernetes itself.
The operator pattern is a perfect match for analytic databases, which are complex distributed applications and may require definition of dozens or even hundreds of individual Kubernetes resources in a running system. Operators encapsulate these details as well as important procedures such as upgrade, scale-out and other operations that require careful manipulation of resources to prevent outages.
It’s not surprising operators are popular with database developers. The OperatorHub.io registry for database operators alone has 19 entries covering databases of every kind, including analytic databases such as ClickHouse and Elastic. Many more exist outside the registry.
New data warehouse architectures and Kubernetes operators means users can now use analytic databases very differently from legacy data warehouses. Our work on ClickHouse, including development of the ClickHouse Kubernetes Operator, prompts two observations.
First, operators make spinning up analytic databases simple and fast for all users. Amazon Redshift kicked open the door to data warehouse-as-a-service in the public cloud. Kubernetes operators enable similar capabilities not just in public clouds but any Kubernetes cluster. Individual developers can cycle through dozens of configurations in a single day while testing new analytic applications. Thanks to quick pod spin-up new analytic databases can be running in minutes or even less.
More profoundly, users can use Kubernetes to move to an on-demand model for analytics. Rather than forcing all applications to compete for resources on a single shared cluster, each application can have an analytic database tuned to its specific requirements. Analytic databases can integrate tightly with applications in the same locations where those applications already run. Businesses can scale databases flexibly to deliver quality analytics at exactly the time they are needed and at reasonable cost. This is the heart of the cloud-native programming model.
Modern database architectures combined with Kubernetes features, such as the operator pattern, are creating a new path to manage enormous volumes of data. For readers who are hesitant about managing data on Kubernetes, it’s time for another look.
To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.
Kong today announced today two offerings that rely on artificial intelligence (AI) to automate the management of application programming interfaces (APIs).
The first offering, dubbed Kong Brain, collects data from any existing platform to auto generate documentation, which can then be used to automate the configuration of the Kong Enterprise API management platform.
The second offering, dubbed Kong Immunity, leverages machine learning algorithms to analyze traffic patterns to first define normal traffic and then train models to automatically detect any anomalies and issue alerts when those anomalies are detected.
Kong CTO Marco Palladino said Kong Brain is intended to make it easier to manage APIs across a modern IT environment by making it possible to continuously reconfigure APIs as new code is added to any platform connect to Kong Enterprise.
In addition, Kong Brain makes it simpler to visually map services and their endpoints to provide deeper visibility into API traffic and the health of any given service, said Palladino.
Kong Immunity, meanwhile, enhances the overall security of the IT environment by identifying potential threats before they proliferate across the API ecosystem, he notes.
Available under an early access program, Kong Brain and Kong Immunity represent the first steps toward employing AI to layer a central nervous system that automates governance, security ad documentation while increasing the reliability of the overall API ecosystem, Palladino said.
As microservices specifically and IT in general continue to evolve, the number of dependencies that will exist across the IT environment will far exceed the ability of any IT staff to manage manually. That issue will become especially acute as more organizations embrace applications based on microservices, Palladino said, because each microservice within that application has its own set of APIs that need to be managed. While Kong Enterprise can support both microservices and traditional monolithic applications, Palladino expects the proliferation of microservices across multiple cloud platforms to force the need to adopt API management platforms infused with AI.
Obviously, the introduction of AI into IT environments will have a profound impact on API management and associated DevOps processes. While developers typically create APIs, responsibility for managing APIs has been shifting to IT operational teams. By adding AI to API management platforms such as Kong Enterprise it should become significantly easier for any enterprise to manage APIs at scale. Of course, AI models don’t work out of the proverbial box. But as the machine learning algorithms that drive those AI models become more familiar with the IT environment, the more automated the management of the APIs distributed across that IT environment becomes.
What impact AI will have on DevOps processes remains to be seen. But it’s increasingly clear that AI will be applied across the IT operations spectrum. In theory, the more automated IT operations becomes the more resources any organization should be able to shift toward developing more applications, which naturally generates more APIs to be managed. It may take a little more time before most organizations have enough confidence in AI to make that transition. But at this point, it’s not so much a question of whether AI will be applied to IT operations as much as it is to what extent.
NGINX this week announced it has developed a common framework for managing application delivery that can be applied across both monolithic and microservices-based applications.
Announced at the NGINX Conf 2018 conference, the NGINX Application Platform has been rearchitected to provide traditional load balancing capabilities and a web application firewall (WAF), as well as a built-in service mesh for managing microservices and an integrated application programming interface (API) management platform.
Sidney Rabsatt, vice president of product management at NGINX, said an update to NGINX Controller is at the heart of a much more comprehensive to approach to integrating load balancing, service mesh technologies and API management. Due out later this year, NGINX Controller 2.0 is based on a modular architecture that enables additional functions to be added via plug-in modules. The module for API management is slated for release in the fourth quarter, while the service mesh module is scheduled to become available in the first half of 2019.
Rabsatt said it’s become clear IT organizations don’t want to replicate existing application delivery controllers just to manage microservices. There will never be such a thing as an enterprise IT environment this is made up entirely of microservices. The latest release of the NGINX Controller makes it possible to manage application delivery across the broad spectrum of applications that need to be addressed within modern IT environments, he said, noting that in effect, it’s a one-size-fits-all approach to managing application delivery via a single fabric.
As part of that effort, NGINX this week also revealed that NGINX Plus R16, an enterprise-grade version of the core NGINX load balancing software, has been updated to apply load balancing algorithms to microservices running on Kubernetes clusters, in addition to support for Amazon Web Services (AWS) PrivateLink integration.
Finally, NGINX announced version 1.4 of Unit, an open source web and application server that support TLS encryption, dynamic reconfiguration via an API and experimental support for JavaScript with Node.js to extend existing support for Go, Perl, PHP, Python and Ruby languages support. Full support for JavaScript and Java is planned for 2019.
In general, Rabsatt said it’s clear organizations that have embraced DevOps are the most advanced when it comes to the need to unify management of application delivery. In fact, much of the recent success NGINX has enjoyed as of late starts with developers downloading an open source instance of NGINX to embed within their applications. As those instances of NGINX start to proliferate across the enterprise, more IT operations teams become exposed to the rest of the NGINX platform.
It may take a while for microservices-based applications to achieve enough critical mass to force organizations to rethink their approach to application delivery. But it’s now a matter of time before organizations need to decide the degree to which they want to deploy standalone application delivery controllers and service meshes for microservices applications instead of pursuing a more hybrid approach. NGINX is clearly betting on the latter, given the number of legacy monolithic applications that will be running for years.
