Modernizing and Dynamic Infrastructures

Modern Digital Applications with Lee Atchison

In this episode, Our customers depend on them, and our businesses depend on them. Without modern web apps, most businesses would not survive. This is the second in a two part series on the principles for modernizing your enterprise web application.

And then, what is STOSA and how does it help with modern digital applications?

Links and More Information

The following are links mentioned in this episode, and links to related information:

• Modern Digital Applications Website (https://mdacast.com)
• Lee Atchison Articles and Presentations (https://leeatchison.com)
• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)
• STOSA — Single Team Oriented Service Architecture (https://stosa.org)

Main Story - Five Principles for Modernizing Your Enterprise Web Applications, p2

Modern web applications have a lot riding on them. Our customers depend on them, and our business depends on them. Without modern web applications, many businesses would not survive. Modern web applications must scale to meet our biggest needs without suffering outages or other availability issues. In order to meet and exceed this high bar, we must build, manage, and monitor our applications using modern principles, processes, and procedures.

There are five guiding principles that a modern application requires in order to meet these expectations.

In previous episodes, we discussed principle 1, using service-based architectures; principle 2, organizing teams around services; and principle 3, using DevOps processes and procedures.

In this episode, we will finish the remaining two principles. Starting with…

Principle #4. Use dynamic infrastructures.

Customer traffic loads on our applications vary considerably. The upper bound or maximum amount of traffic your application needs to support can never be known accurately.

In the past, as application traffic grew, we simply threw additional hardware at the problem. But as traffic variations increase, and customer usage patterns become more complicated. This simple solution is no longer reasonable.

Simply adding hardware may be fine to handle expected peaks, but what do you do when an unexpected spike in usage arrives? When I was at Amazon, there was a term that was used. It was called the “Johnny Carson Effect”. It’s origin comes from the day that Johnny Carson died. On that day, there was a huge uptick in demand for any videotape of old episode’s of Johnny Carson’s The Tonight Show. Demand was huge, and given the suddenness of the event, it was all unexpected demand. Now-a-days, the term “going viral” is both a positive and a negative for most businesses. Going viral means huge attention given to you and your business. But it also means huge and unexpected traffic volume. The last thing you want is for your application to fail right at the point when everyone is watching.

How can you handle the unexpected surge from such an unexpected event? It is no longer possible to throw large quantities of hardware at an application. You never know how much hardware is enough hardware to handle your possible maximum need.

Additionally, when your application is not operating at a high volume, what do you do with the extra hardware? Typically, it’s sitting idle...which is a huge a waste of resources...and even more importantly...a waste of money. Especially if your traffic needs are highly variable or highly spiky, simply adding hardware to handle your peaks is not an effective use of resources.

Instead, you must add resources to your applications dynamically, as they are needed and when they are needed. These resources can be applied when your traffic needs are high, and they can be released when they are no longer needed. This is what dynamic infrastructures are all about.

The only way to implement a true dynamic infrastructure for an application with a highly variable load is to use the dynamic capabilities of the cloud. In the cloud, resources can be added on demand, and released when they are no longer needed, becoming available for other uses. To be successful, modern applications must make use of dynamic infrastructures to not only optimize their operational costs, but maintain availability during all types of traffic patterns.

I have many articles I’ve written, and I’ve given many talks on dynamic infrastructures and the dynamic cloud. For more information, go to leeatchison.com and click on “Articles”, or click on “Presentations”.

Principle #5. Maintain high visibility into all aspects of your application.

It is impossible to keep a modern application working if you do not have visibility into what your application is doing and how it is performing.

This is a basic truism of modern applications.

Without proper visibility into the operation of your application, you have no idea if the application is meeting the needs of your customers, or of your business.

Without proper visibility, you have no way of knowing if a ticking time bomb is ready to go off and make your application suddenly unavailable.

**With** proper visibility, you can understand what your application is doing, you can understand how it’s doing it, and you can understand if there are any lurking issues that might impact the application’s ability to perform those operations in the foreseeable future.

Further, while using tools such as synthetic testing and infrastructure performance monitoring is important, this level of monitoring is not sufficient.

You cannot completely understand how your application is performing without an internal view of its operations. This point is worth restating. You cannot understand how your application is performing without an ***internal*** view of its operation.

This is only possible using application performance monitoring, log monitoring, and trace analysis. These three tools are critical to the ability to have proper visibility into the operation of your modern application.

With proper visibility, comes the ability to build and maintain your ever growing, ever more complex, modern applications.

That’s it, that’s the last of the five principles required to modernize your enterprise applications. In summary, the five principles are: Use service-based architectures, organize your teams around your service architecture, use DevOps principles methodologies, use dynamic infrastructures, and maintain high visibility.

Our applications *are* getting more complex, and becoming more intertwined with the fundamental operation of our business. As such, the expectations of our customers...expectations on reliability, functionality, and availability...continue to grow. As we modernize our applications to meet these growing needs, these five principles will you meet the needs of your customers and your business.

More information on these five principles is available in my article published in InfoWorld, “How to modernize enterprise web applications”. A link to this article is available in the show notes.

Tech Tapas

Single Team Owned Service Architecture ... STOSA.

STOSA is an operational model for how to structure your organization to effectively manage a multi service or micro service architected application. For your teams and organization to be STOSA compliant, they must:

Have an application that is constructed using a service-based architecture or a microservice-based architecture.

Have multiple development teams that are responsible for building and maintaining the application.

Each and every service in your application must be assigned to a development team, who owns that service. The team that owns each service should be well documented and readily available to everyone in the organization.

No service should be assigned to more than one development team, however individual development teams may own more than one service.

Teams are responsible for all aspects of managing the service, from service architecture and design, development, testing, deployment, monitoring, and incident resolution.

Services have strong boundaries between them, including well-documented APIs.

The service owns its own data. Data is part of the service. If a service needs to access data stored in a different service, it must use one of the well-documented APIs to access that data.

Services maintain internal service-level agreements (SLAs) between them that are monitored and violations reported to the owning team.

A STOSA-based application is an application for which all services follow these rules. A STOSA-based organization is one in which all service teams follow the preceding rules and all applications are STOSA applications.

I developed this model based on my experiences building and operating large scaled applications. The model first appears in my book Architecting for Scale, by O’Reilly Media.

You can learn more about the STOSA model by going to stosa.org. That’s s-t-o-s-a-dot-o-r-g.

Links are available in the show notes.

This podcast uses the following third-party services for analysis:
Chartable - https://chartable.com/privacy
Podtrac - https://analytics.podtrac.com/privacy-policy-gdrp