8 Experts on Flawless App Delivery

Sponsored by
Building a Flawless
High-Growth Application
Delivery Solution That Can
Withstand Disruption
Flawless
App Delivery
8 Experts on

2
INTRODUCTION
In a world of distributed computing and componentized applications, securely building and deploying
a successful application are challenging. Poor execution can result in underperforming apps, security
risks, and unacceptable infrastructure costs.
Successful application delivery depends on the tools and services you use to build, deploy, and
monitor your applications, but what is the “right kind” of application-delivery system? With the
generous support of Citrix, we set out to learn more about application-delivery challenges and
solutions by asking eight experts the following questions:
• What challenges do you encounter when selecting an application infrastructure? What are the
major considerations?
• What are the major factors that slow down app production? Once an app is in service, what
are the challenges of scaling it cost-effectively?
• What are the biggest challenges you face in securing your apps and data? How do you
address them?
• How does visibility across systems factor into troubleshooting a problem quickly?
Not surprisingly, the answers depend on the nature of the application. This eBook provides insights
from different perspectives that will be useful to anyone managing an agile application-development
and delivery process.
Mighty Guides make you stronger.
These authoritative and diverse
guides provide a full view of a topic.
They help you explore, compare, and
contrast a variety of viewpoints so
that you can determine what will work
best for you. Reading a Mighty Guide
is kind of like having your own team
of experts. Each heartfelt and sincere
piece of advice in this guide sits
right next to the contributor’s name,
biography, and links so that you can
learn more about their work. This
background information gives you
the proper context for each expert’s
independent perspective.
Credible advice from top experts
helps you make strong decisions.
Strong decisions make you mighty.
© 2020 Mighty Guides, Inc. I 9920 Moorings Drive I Jacksonville, Florida 32257 I 516-840-0244 I www.mightyguides.com
All the Best,
David Rogelberg
Publisher, Mighty Guides, Inc.

We live in a technology-driven world. With businesses more dependent than ever on applications that
power critical operations and customer engagement, the value of delivering the best, most secure user
experiences has never been greater. That is the role of an application-delivery platform such as Citrix
Application Delivery Management.
At Citrix, we recognize both the importance and the challenges of delivering applications in a way
that keeps businesses secure and competitive. With the transition to cloud computing, these
challenges have grown. Today’s applications run on containerized functionality distributed across
hybrid multicloud environments. Without good visibility across all these environments, it is difficult to
configure, troubleshoot, and economically scale applications.
Citrix Application Delivery Management addresses these challenges by delivering applications across
any environment, including on premises, public and private clouds, and any hybrid architecture. It
provides automated configuration and auto-scaling so that organizations can rapidly roll out new
functionality and quickly adapt to shifting load requirements.It also uses analytical machine learning
to identify unusual application activity.
We supported the creation of this eBook to shine a light on the many application-delivery challenges
that information technology professionals face every day. We are delighted to see that it has handily
accomplished that goal. These are the challenges that Citrix Application Delivery Management is
designed to address.
We hope you enjoy this eBook.
Regards,
Meerah Rajavel
Chief Information Officer, Citrix
Citrix (NASDAQ:CTXS) is powering
a better way to work with unified
workspace, networking, and analytics
solutions that help organizations
unlock innovation, engage customers,
and boost productivity, without
sacrificing security. With Citrix, users
get a seamless work experience
and IT has a unified platform to
secure, manage, and monitor
diverse technologies in complex
cloud environments. Citrix solutions
are in use by more than 400,000
organizations including 98 percent of
the Fortune 500.
FOREWORD
3

4
TABLE OF CONTENTS
CHAPTER 1
Choosing the Right Application Delivery Infrastructure 6
CHAPTER 2
Increasing Speed and Enhancing Performance 19
CHAPTER 3
Protecting Your Application and Securing Your Data 36
CHAPTER 4
Rapid Troubleshooting 52

MEET OUR EXPERTS
ADAN POPE
Serial CTO and Innovator
BRIAN BOBO
CIO & CISO
Greenway Health
KEVIN L. JACKSON
COO
SourceConnecte
CÉCIL BOVE
Senior Sales Engineer Manager,
Cloud-based Company
ROBERT BURTON
Cloud Security Architect,
Bupa; Director, RJME
Property Investments Ltd.
JONATHON WRIGHT
Co-Founder | CTO,
Digital Assured
JAMES HUGHES
VP of Sales Engineering,
Enterprise CTO, Rubrik
DR. IR JOHANNES
DROOGHAAG
CEO , Spearhead Management

6
When building a new application, the first challenge you face is choosing the technology infrastructure you
will use to manage the continuous development and delivery workflow. With so many solution options,
where do you even begin? To find out, we asked the experts the following question:
• What challenges do you encounter when selecting an application infrastructure?
• What are the major considerations?
CHOOSING THE RIGHT
APPLICATION DELIVERY
INFRASTRUCTURE
CHAPTER 1

Adan K. Pope is a leading authority
on digital transformation, strategic
technology leadership and disruption
with over thirty years of career
experience. He has held almost every
role in software technology innovation
and development from developer
to chief technology and innovation
officer for some of the most innovative
technology companies including
Ericcson, ShopperTrak, Ciena, and
InnerWorkings. He holds Masters
degrees in Computer Science and
Business Administration from North
Central College and a BSEET from
DeVry.
Adan Pope, Serial Chief Technology
Officer and Innovator
7
InnerWorkings.
“The platform should provide access controls
and authentication management for all
applications and application components.”
The application infrastructure you choose depends on several factors,
including what business objectives you are trying to achieve and the
value the business will deliver through its applications. This choice
usually comes down to cost, scale, and elasticity; a look at where
the infrastructure will go in the future; and where you are now with
applications and infrastructure.
In today’s world of distributed compute applications, an application
infrastructure must be based on a platform that supports these three
essential functions:
• Access and authentication. The platform should provide access
controls and authentication management for all applications and
application components. Information technology (IT) organizations do
not need to build these things themselves because many companies offer
excellent solutions that can become part of an application infrastructure.
• Common data stores. Data management for an application should be
a platform capability. Applications should not be built with bespoke data
stores or tightly held and encapsulated data stores. Data should be on the
platform but outside the applications.

8
• Common messaging. A messaging infrastructure should enable
you to decouple message senders from message consumers.
For more flexible applications, you want to avoid point-to-point
messaging in applications.

As chief information security officer,
Brian Bobo leads Greenway’s IT
organization, overseeing the hosted
environments of thousands of
customers. Passionate about building
teams and fostering collaboration,
Brian is skilled at creating long-term
cyber strategies. He brings experience
from the aviation, retail, manufacturing,
and logistics industries as well as the
military.
Brian Bobo, CIO & CISO, Greenway
Health
9
military.
Health
“When making infrastructure decisions, choose the best
balance of costs and performance. . . . Your infrastructure
must ultimately support the balance you choose.”
When making infrastructure decisions, think about who’s going to be using
the application, what kind of performance you need, the amount of data
you are working with, disaster recovery (if data is critical), and costs. There
are advantages to putting things in the cloud, but depending on data usage,
a cloud solution comes with a cost. Choices such as serverless computing
architectures, where the infrastructure automatically allocates resources,
can make cost projections difficult. If you have high data demands, you
may want to use a hybrid solution that puts metadata in the cloud and
keeps the actual data in on-premises storage. That decision, however,
introduces new operational and performance challenges.
We are currently transitioning legacy electronic health record applications
to the cloud. Our applications, which run high input/output per second,
were not written for the cloud, so just transferring that code to the cloud
will not work. In addition, we have to be careful how we transition because
even if we get the applications running smoothly in the cloud, putting all the
health data there would be too costly.
When making infrastructure decisions, choose the best balance of costs
and performance. There may be many good reasons to go to the cloud,
but financial return may not be one of them. Your infrastructure must
ultimately support the balance you choose.

Cécil Bove has more than 12 years of IT
experience with large customers. Currently
senior sales engineer manager for a
cloud-based company; Cécil has built and
led presales and consulting teams for
software vendors and systems integrators.
His technical background combined with
his business acumen enable him to offer
solution-oriented approaches to resolving
challenges in the most demanding
environments.
Cécil Bove, Senior Sales Engineer
Manager, Cloud-based Company
10
environments.
10
“The best application platform will be the one that
supports your application’s requirements, so it is
important to think through these details before settling on
a specific application infrastructure.”
Choosing the right application infrastructure is a big and important decision from
the start. The infrastructure you choose guides your application’s performance
and its ability to scale in the future. It also establishes underlying technological
choices that can be difficult to change once the application has been built. To
choose a platform for a new application, thoroughly review the nature of the
applications you are building, which means looking at the application from
multiple angles:
• Is it a new application, or is it an existing application that you want to move,
change, or enhance with new features?
• Who will the application’s users be? Will users access the application through
application programming interfaces, or is the application customer facing?
Does the app have special user interface requirements? Is the application
public or private? Where are its users located?
• What kind of data will the application access and store? What will the
network bandwidth requirement be?

11
• What are the scalability requirements? Some applications will
not grow over time, while others may start small, and then grow
to support many thousands of users. Your platform should
support both growth scenarios.
• Security and data sovereignty are key considerations. You
need to know what types of data you have, where it will be kept,
and the kind of security and data management controls you
will need to support. These factors are especially important
in Europe, which requires compliance with the General Data
Protection Regulation. You will also need to understand the
kinds of security threats your application is likely to face.
The platform you choose depends on your application’s use cases.
The best application platform will be the one that supports your
application’s requirements, so it is important to think through these
details before settling on a specific application infrastructure.
A good platform will support application operations after the
application has been built, so it’s important that the DevOps team
be able to manage it. Finally, the platform needs to fit your budget.
Based on your requirements, compare platforms from a technical
standpoint as well as from a financial perspective.

James Hughes is VP of Sales Engineering
and an enterprise CTO at Rubrik. James
joined Rubrik from Schroders, where he
was global head of Infrastructure & Shared
Services Technology. Before that, he was
head of Production Services at Premium
Credit, VP of Infrastructure at PIMCO, and
head of Central IT for Investec Bank Plc.
He is a Chartered Information Technology
Professional with the British Computer
Society and a board member of several
governance and standards bodies.
James Hughes, VP of Sales
Engineering, Enterprise CTO, Rubrik
“When thinking about an application-delivery
solution, first look at the problems you are
trying to solve.”
When thinking about an application-delivery solution, first look at the problems
you are trying to solve. Too often, developers pile straight into the technology
without really thinking about what their output needs to be. Begin by asking
what the business needs to accomplish, who the clients are, how available the
system needs to be, what other applications it will interact with, whether the
application will be regulated, and what kinds of reporting will be required. Think
through the application’s operational functionality and the user experience.
Once you have worked out those details, then you can go into solutions
mode, deciding what you will need to support delivery of your application. A
key question is whether that delivery mechanism is something you build or
something you buy. Which route you take depends in part on the ecosystem
integrations you need and the skills required to build and support the
application. Time to market is another important consideration, as is the
nature of the application. For example, a highly customized, high-volume
trading platform will have different infrastructure requirements than a more
typical business process or transactional application.
Ultimately, you want to avoid complexity. Focus on the outcomes first, then
look at what you need to support them.
12

Early in his career, Johannes Drooghaag
realized that the development of
technology outpaces the development of
our understanding of technology. Working
based on the principal that we don’t have
to understand the bits and bytes to use
technology, but we must understand how
to use it optimal and secure, Johannes
developed consulting services, training
programs, keynotes and workshops to
allow people and organizations to do just
that: embrace technology in the optimal
and secure way.
Dr. Ir Johannes Drooghaag, CEO,
Spearhead Management
13
and secure way.
“Your application’s value, security, and accessibility
requirements are key considerations in platform
capabilities, but there are other things to think about, too.”
One challenge businesses, especially startups, face in choosing the right infrastructure
is the number of choices available to them. The platform is an instrument for creating
what you want to offer. To make a platform choice, you need to match platform
functionality to what you want to accomplish.
When looking at your functional objectives and putting them into business context,
three considerations are critical. One is the value you are going to achieve and how
you will deliver that value through the application. The second is security, which is
a fundamental risk to business success. There is never a phase in your project or in
your product life cycle where you cannot focus on security. Third is accessibility and
inclusion. Design thinking that focuses too narrowly on the optimal customer group can
result in the application design being less than optimal for large segments of potential
customers.
Your application’s value, security, and accessibility requirements are key considerations
in platform capabilities, but there are other things to think about, too. Many application
efforts begin with a small team focused on getting core functionality up and running.
They are not thinking about the future growth of their development team or the future
scalability of their application (although these things must be considered). What
happens if instead of just a couple of developers focusing on one app, your team grows
to having many developers working on twenty or fifty applications? The platform must

14
facilitate collaboration and include workflow-management tools to
support this scale of work. As applications are launched, they will need
to scale, so the platform must support scalability. Deciding on the right
application architecture requires looking at application requirements
now as well as where you expect them to be in the future.

Jonathon Wright is a strategic thought
leader specializing in emerging
technologies, innovation, and
automation. With more than 25 years
of experience in global organizations,
he is a frequent speaker at TEDx,
Gartner, Oracle, AI Summit, ITWeb, and
Unicom. Jonathon is the QA lead for
the COVID Safe Paths MIT project and
part of A.I. Alliance for the European
Commission. He is also the host of
The QA Lead podcast.
Jonathon Wright, Co-Founder |
Chief Technology Officer, Digital
Assured
15
Assured
“Infrastructure decisions are becoming more complex
as application architectures move from microservices to
nanoservices, with the growth in service mesh architectures,
and the increasing use of graph database queries.”
Fundamental considerations must include the type of application you are
developing and the market segment it serves; the kind of development
and delivery process you have; and the capabilities you have in house with
regard to people, processes, and technology. Underlying all those must be an
understanding of the business and organizational goals of the application.
Infrastructure decisions are becoming more complex as application
architectures move from microservices to nanoservices, with the growth
in service mesh architectures, and the increasing use of graph database
queries that draw on data from many sources. In complex applications,
particularly those that employ machine learning and artificial intelligence (AI),
it’s possible to go too far in choosing technology and an architecture just to
understand whether you can achieve the goal. For that reason, more and more
organizations are adopting a lean startup approach in which many technology
architectural decisions are left until the product investment phase is past the
early adopters.
As applications become more componentized, they do not easily conform to
the traditional format tier–application tier–data tier architecture. Containerized
models built with an architecture that supports multicloud deployment depend
on many components. For many of these applications, data is by far the most

16
important aspect, which means that a lot of engineering activity is
required as a prerequisite to any data science activities related to those
applications. For each application component, the application platform
must support data visualization, the computer vision, and the ability to
store large amounts of data.
So, the key capabilities of the AI application-delivery infrastructure
must include an architecture that supports multicloud deployment so
that you can move between cloud vendors, total visibility across all
application components, and the ability to store large amounts of data.
In this kind of service mesh, with many components moving around,
delivery is considerably more challenging than in the traditional three-
tier architecture.

17
17
“An application infrastructure needs to be flexible enough
to support multiple types of endpoints, and it must support
a back end that is likely to run in a hybrid IT environment.”
Application infrastructure is critical because it can determine how your users
collaborate and communicate with your organization through that application.
Regardless of the actual business function or process your application
implements, targeted users need to feel that the application is easy to use and that
they can get to it anytime they want. Many organizations know what they want the
application to do, but they fail to explore all customer use cases thoroughly.
An application infrastructure needs to be flexible enough to support multiple
types of endpoints, and it must support a back end that is likely to run in a hybrid
information technology (IT) environment. By hybrid IT environment, I mean
an environment that can include multiple clouds as well as a traditional data
center and managed service providers. Flexibility and interoperability are key
characteristics of a good application infrastructure. You need the ability to lead
your prospective customers in the direction they want to go. If you lock yourself
into a single cloud service provider by designing your application based on that
provider’s services, you lose flexibility.
Kevin L. Jackson provides consulting and
digital media services to AT&T, Intel, and
Ericsson and is an adjunct professor at
Tulane University. In his career, he has
been a vice president of JPMorgan Chase,
a worldwide sales executive at IBM, and
director of cloud solutions for SAIC (Engility).
Kevin holds an MS in computer engineering
and a BS in aerospace engineering. He is the
author of Click to Transform and Architecting
Cloud Computing Solutions.
Kevin L. Jackson, COO,
SourceConnecte

18
18
Robert Burton is an IT professional with 40
years of experience in operations, application
development, configuration management, and
cloud services management. He is an ITIL
Expert and CCSP, and he has significant project
management expertise. I studied in Cape Town,
South Africa, obtaining a postgraduate diploma
in management information systems. I am
married with two grown children, both of whom
hold master’s degrees in scientific fields.
Robert Burton, Cloud Security
Architect, Bupa; Director, RJME
“Understanding your target audience in terms of its
size and usage patterns, how the application will
look to users, and which application components
they will use most.”
A key challenge is understanding what you are trying to deliver to users so that
you can design your infrastructure to service that application appropriately. This
means understanding your target audience in terms of its size and usage patterns,
how the application will look to users, and which application components they will
use most. You need to shape your infrastructure to meet that service requirement.
Then, you must build your infrastructure so that you can maintain it without having
to take it down. Make sure that your infrastructure is built in such a way that you
can remove pieces, work on them, and then phase them back in. To do that, you
must structure the application as a collection of microservices integrated through
common message formats rather than monolithic code. In that way, you can swap
functionality in and out without disrupting service, which gives you the ultimate
flexibility of changing components without having to rebuild everything.
The day of the monolithic application is gone. Tightly coupled applications are
difficult to troubleshoot and maintain. We now live in an application programming
interface (API)–centric world. Maintenance is faster and easier when applications
are built on microservices linked by APIs.

19
A key factor in building successful applications is time to market. The ability to develop and deploy critical
functionality quickly can have a big impact on the business. When an application has been deployed, the way
it scales affects operational costs. To learn more about these aspects of application development, we asked
the experts the following question:
What are the major factors that slow down app production?
Once an app is in service, what are the challenges of scaling it cost-effectively?
INCREASING SPEED AND
ENHANCING PERFORMANCE
CHAPTER 2

20
“A reference architecture and coding
standards facilitate building an independent,
component-based architecture.”
A lot of development work involves shifting workloads to the cloud.
Depending on the nature of their IT environment, one challenge for
development teams is deciding where development efforts will deliver
the greatest value to the business. In complex environments with many
technologies and legacy applications, you need to review applications and
make componentization decisions based on the need to scale to meet
user or data demands.
A reference architecture and coding standards facilitate building an
independent, component-based architecture. Having those standards and
reference architecture ensures that you’re not rebuilding the same things
over and over. If a team is developing something that provides value
beyond what that one team is doing, it’s important to build a framework
others can use to develop other components.
A big challenge to increasing throughput of a development organization
is understanding what throughput actually is. You should have objective
metrics in place rather than just an agile scrum team that counts the
number of story points it accumulates by resolving tickets. Ultimately,
InnerWorkings.

21
you must have a common understanding of what throughput really
looks like—namely, the amount of work a team can do over a period
of time. You need to see how much of what you’ve completed in
code and testing is actually getting into production. The definition
of done is often debated, but for me done means code or test
complete and in production, serving customers.
When scaling applications, consider the cost and the benefit. For
example, scaling legacy applications is difficult because these
applications are generally monolithic. To scale a monolithic
app, you might have to run a second instance, which can be
costly. That is the big advantage of distributional workloads
and componentization of applications into microservices. With
componentization, you can do more automated load balancing to
get maximum performance and resource utilization for workloads
you have shifted to the cloud. It also simplifies the management of
application delivery.

22
“Application scalability goes back to the essential
design and intent of the application . . . . You must plan
for these elements early in the development process.”
Two factors that hinder application development are keeping requirements
stable during the development process and lack of quality output.
When new ideas keep coming up during the development process, you
can quickly have more requirements than it’s possible to develop. Make
sure that your requirements are reasonable and that the core requirements
stay relatively static during development. That means having a process
and tools that enable you to decide what is most important and having the
ability to prioritize so that you can keep the development team focused on
those important things.
Quality is another important issue. If you try to go too fast and quality
suffers, you’ll have to go back and fix things—including security. Instead,
foster a DevSecOps mentality, and treat security issues the same way you
would treat any other quality issue. You must understand what needs to be
fixed and what doesn’t, and then stay on pace.
You can really accelerate the development process by creating reusable
code and building applications from tested components. You know they
work, and you know that they are theoretically secure. In this way, you can
really accelerate your deployment.
military.
Health

23
Application scalability goes back to the essential design and intent
of the application; understanding who is going to be using it; and
knowing what demands, such as data consumption, that use will
place on the infrastructure. You must plan for these elements early in
the development process. Although in our case user demand is fairly
stable, having a cloud-based solution gives us the ability to scale
quickly.

24
24
“Many companies have pandemic plans, but until they
actually experience a pandemic, they don’t know how far
from reality that plan actually is.”
One factor that can seriously slow down application development is making bad
choices in application architecture or platform. If during the course of application
development you realize that you cannot do what you want or need to do or it
takes much more time than you thought, you will need to find other solutions.
You need to adapt and rethink bits of your application, which can seriously delay
production.
Changes in application requirements often slow the development process.
Think through those requirements at the beginning so that you can choose your
platform and technology. If your requirements change after you start building, you
may need to rethink your application architecture. That’s why it’s so important to
thoroughly vet requirements at the beginning, and then manage changes in a way
that does not slow production.
It’s also essential to consider reusable application components and use existing
libraries or services offered by theplatform. You don’t want to have to build
everything from scratch or reinvent the wheel.
One key factor in increasing development speed is a clearpath between
development, testing, and production. The platform should provide continuous
environments.

25
25
integration and development for your application that is linked to
testing. Testing is often done near the end of the development
process, but it must be more granular than that. Testing should be
part of building your application from the beginning.
Much of the continuous integration, testing, and deployment
pipeline can be driven by automation, which also plays a role in
scaling once an application is in production. There are two kinds
of scaling: One is vertical, in which your application requires more
computational power and RAM, and the other is horizontal, in which
your process requires more services, more containers, and more
virtual machines. Demands on these resources vary depending
on your usage patterns. You need to be able to scale up or down,
although scaling up is often easier than scaling down. To be cost-
effective, however, your infrastructure must follow usage patterns
so that you do not limit application performance or waste your
budget on unnecessary capacity.

“You must consider the operations side, especially
for business-critical applications, because it falls
on the DevOps team to keep everything running.”
A major obstacle to speedy application development, especially in large
organizations, is getting the project off the ground—getting funding, bringing
in the right people, and getting stakeholders to agree on the problem and how
you’re going to solve it.
A key success factor in getting something out the door quickly is the operating
model. The operating model is governed in part by the technology platform
but also by the way the technologies and development process are organized.
The fastest way to get things done is to create an agile framework that all
your developers and infrastructure people use for their work. An agile process
enables you to create a minimum viable product that can be in production
while you iteratively add capabilities.
To do this, you need a solution architecture that provides as uniform and
repeatable a process as possible. Then, you can build reusable microservices
that become building blocks for your application. Microservices make
application development more flexible, but they also present challenges. For
instance, if all your microservices are written in the same language using the
same application programming interfaces (APIs) and run in the same cloud,
that simplifies application development but can create limitations because
26

27
microservices are designed to be much more flexible than that. If
you’ve got many microservices written in different languages running
in different clouds and data centers that are linked only through APIs,
scaling such a solution can be more challenging.
When planning for application scalability, consider technology costs
associated with scaling, such as processing capacity, licensing
fees, and bandwidth. You can optimize these aspects of application
scaling through automation tools. Beyond that, you must consider the
operations side, especially for business-critical applications, because it
falls on the DevOps team to keep everything running.
In DevOps, everyone loves the “dev,” but no one loves the “ops.” For
efficient application delivery, build a proper scale framework on the
operating platform all your developers and infrastructure people will be
working on. With that central application director and proper application
design, you can scale and automate everything, which is why machine
learning has become so important to the operations side. Massive
systems running at scale generate a lot of noise in terms of logs and
data. When you have five problems on your system generating a million
alerts, you need algorithmic information technology (IT) operations
to resolve them. You must consider scalability from the beginning of
application design.

28
“Whenever you make something, you are not just making
it for the specific task or requirement in front of you but to
become part of a repository of functionality.”
One major factor that slows down application development is failure to take the
necessary time to build application components in a way that makes them reusable.
This issue arises almost naturally as developers use an agile process to deliver the
next stage of functionality under tight time constraints. Under such conditions, they
lose sight of the big picture. Then, because they don’t see the value in the moment
of configuring something for reuse, they miss that opportunity. Then, either in a later
stage of development or when working on another application, they create that same
functionality again. In fact, they may end up building the same thing several times.
Instead, make it part of the design concept that whenever you make something, you
are not just making it for the specific task or requirement in front of you but to become
part of a repository of functionality. Then, apply this rule to code development as well as
application delivery infrastructure.
With that mindset, two things happen. First, when you need to build something, your
first thought will be to see if microservices are already available that could save
you time. Second, when building for reusability, work in a templatized development
environment so that the components you build include elements that make them
reusable. Investing that little extra in using templates makes it easier to add and deploy
new functionality without rebuilding earlier releases, which in turn makes applications
more flexible and scalable and speeds the development process.
and secure way.

29
Another obstacle to speedy application development is not adequately
planning for security. When you create something that works and later
integrate it into a bigger environment, if you have not done your security
homework, you may have to retrofit components to meet the security
requirements of the operating environment. This rework costs time and
money. Security must be a red line throughout everything you do from
the beginning.

30
“The key is understanding the workload, and that
begins by turning the DevOps development model
on its head and following more of an OpsDev
approach.”
How you develop code, and then scale an application once it enters production
go hand in hand. In dealing with complex application architectures and AI, the
traditional approach of scaling an app by making more compute resources
available to it does not necessarily increase its operational output or improve
the user experience. Bad code is bad code, and the application will not be
scalable if after the fact you realize that you’ve created dependencies that
aren’t fit for the purpose.
The key is understanding the workload, and that begins by turning the DevOps
development model on its head and following more of an OpsDev approach.
You begin at the right side of the pipeline by modeling effective performance
engineering patterns, determining what they should look like as far as scale,
workload spikes, and longer-term operational outputs. Then, you look at how
you design code and resource requirements to meet those patterns.
In developing and operating AI-based applications, we use an unbreakable
pipeline that is essentially an event-based control plane that sets a traffic
light on each commit. In this way, we can see what is happening in the live
environment. If necessary, we can roll things back, which creates a kind
of self-healing production and operational environment. Then, we use a
machine learning platform for live system tuning. This platform captures
Assured

31
all the application performance management information and looks
across the AI operations landscape for tuning opportunities based
on workload. We use a business modelling application that monitors
the application and analyses code risk. In this way, we can conduct
dependency analysis and monitor performance as the system evolves
day by day. We can prevent problems before they happen in the
continuous deployment pipeline.
Scaling is challenging because the many systems in the cloud are
trying to perform complex functions. The bottleneck is not always tied
directly to the System resources available to specific microservices
or nanoservices in your application. Therefore, you must understand
vital upstream and downstream systems. Also, you must conduct
performance modelling based on consumption workloads and future
workloads, which is challenging for AI operations because people
generally look only at what they can and cannot control and manage
an application programming interface (API) mediation strategy that
optimizes the things they can control. AI-based applications, however,
become meshes of services built on top of services. To optimize AI
operations, you need visibility into those dependent services that may
not be in your control. Those services become your bottlenecks.
AIOps is the ability to predict the impact of systems, systems
behaviours, and deployments by modelling the infrastructure
configuration against certain types of workload. It uses large data
sets and machine learning to create scenarios for events that haven’t
happened yet.

32
32
“Using standardized modules to build loosely coupled
applications is the foundation of success in today’s cloud
computing world.”
Building an application efficiently and ultimately making an app that scales comes
back to basic application design. Insufficient modularity in the application design
and a failure to enforce standards across the application and infrastructure
platform will slow the development, deployment, and production of any
application. Without standardized modules, you end up negotiating every interface
between every module. If you adopt and enforce standards, your developers can
quickly build modules and microservices, and then rapidly integrate, test, and
deploy them.
This approach requires modularity in application design and the use of consistent
templates. The modules and microservices themselves must be standardized and
uniformly adopted across the enterprise. This is as much organizational policy
enforcement as it is a technical issue.
Using standardized modules to build loosely coupled applications is the
foundation of success in today’s cloud computing world. A loosely coupled
application is one that consumes standardized services that are independent of
the technology being used to deliver them. An application design that depends
on tight coupling to specific cloud technologies can simultaneously kill scalability
SourceConnecte

33
33
and portability, which is why the “lift-and-shift” approach to cloud
migration fails, particularly in the case of load balancing. Traditional
data center load balancing requires manual configuration to fixed
computing resources, but cloud applications use virtual services
that come and go automatically as needed. To perform well in the
cloud, applications require automated load balancing that adjusts
resources dynamically to meet user and computing demand.
Performance may also depend on accessing resources spread
across different clouds. Loosely coupled application services
enable you to build auto-scaling into your application so that its
services will work throughout the available IT infrastructure.

34
34
“The platform must intelligently analyze application
usage so that you can make code adjustments to
improve the application’s operation.”
In my experience, a significant obstacle to timely completion of an application
development project is scope creep. Scope creep happens because of poorly
defined requirements, which is why it’s so important to define application
requirements up front and stick to them. You may need to adjust those
requirements initially, but once you have settled on a scope, build to that scope. If
somebody wants to add something, that deliverable becomes part of the delivery
backlog: It shouldn’t hold back application deployment.
Once you begin developing, the best way to deliver an application or service is
in bite-sized pieces of usable functionality. Create a rollout plan that delivers the
most important functionality first, then choose an application framework with
hooks built into it that enables delivery to different operating systems, browsers,
and processor types. That’s how you quickly roll out applications to any platform.
It’s also important to monitor application usage and performance. The platform
must intelligently analyze application usage so that you can make code
adjustments to improve the application’s operation.
Scaling an application is another important consideration that ties back to
application requirements and workload expectations. To prepare to run your
application at scale, pay particular attention to the following elements:

35
35
• Operational capacity. Have you built your infrastructure so that it has the
capacity to scale to meet requirements, even if that means scaling infinitely?
• Monitoring. Can you see how the application is using the infrastructure and
what its scaling patterns are?
• Licensing costs. Do you know the cost of scaling all the components of your
application, such as database licensing? Do you have flexible licensing and
cost structures?
• Network capacity. Will your network support massive scaling?
It’s important that you be able to change scaling parameters so that you can meet
application demands during peak usage, and then scale back to lower capacity
when demand falls. You also need the infrastructure to meet peak demand. You
can set your application to scale infinitely, but do you have the capacity to meet
that demand?
Proper scaling requires that you have the ability to monitor demand and identify
usage patterns so that you can provision correctly and anticipate the costs of
provisioning for those levels of demand. Such analysis helps you decide whether
it’s more cost-effective to allocate a load to a large server or split it load across
many smaller ones—an important feature, especially when using pay-as-you-go
cloud services.
At some point, if your application becomes massively successful, you may not
want to own the load-balancing and capacity management side of it. In that case,
consider having the cloud platform manage those aspects for you. Then, you can
focus on maintaining your app and making sure that your revenue stream is better
than what you are paying out for application delivery infrastructure.

36
PROTECTING YOUR
APPLICATION AND SECURING
YOUR DATA
CHAPTER 3
Security is the challenge that never ends, and with distributed applications and decentralized computing,
security risks are as great as they have ever been. How do IT teams address cyber risk as part of application
delivery? To find out, we asked our experts the following question:
What are the biggest challenges you face in securing your apps and data?
How do you address them?

37
“[An] invaluable tool for a complex application
environment is an artificial intelligence/machine
learning tool that monitors all traffic and activity
in the environment and alerts you to anything
suspicious.”
The biggest challenge with security is trying to manage the unknown. It
keeps you awake at night.
In a hybrid environment, you need a hardened perimeter on fixed assets,
such as a corporate data center; with load-balancing and network policy
controllers, you need plenty of firewall protection, as well. Encrypting data
at rest and in flight is important. Another invaluable tool for a complex
application environment is an artificial intelligence/machine learning tools
that monitors all traffic and activity in the environment and alerts you to
anything suspicious.
Application programming interface (API) authentication is also important.
I have found it valuable to ensure that every API has secure keys and
performs a handshake for authentication. It is also critical to implement
tools that enable the verification that an API call has been authorized.
Another best practice, outside your internal domain, is to ensure that all
access of this type require multifactor authentication.
When workloads are moved to a major cloud provider environment, I
have seen that the level of security goes up dramatically, assuming that
InnerWorkings.

38
the services and security controls have been properly configured
and managed. IT budgets are usually tight and the allocation for
implementing security tools is limited: The cloud provider is simply
not similarly constrained.

39
“The biggest risk is balancing usability with
security requirements to keep users safe.”
For us, there are customers and there are patients. The customers are
the doctors and the patients are their customers, but we need to protect
everybody in the loop. The biggest risk is balancing usability with security
requirements to keep users safe. In some ways, you’re trying to keep them
safe from themselves.
Depending on how your users interact with your application, especially
when you’re dealing with the cloud, you have to make sure that users have
strong passwords and require multifactor authentication (MFA). You could
potentially have an exposed web portal with a log-in that anybody could
access. This also goes back to the nature or your application and its users.
For example, some of our patient portal users are visually impaired, and
some of them struggle with the technology. The challenge is how you keep
users safe without the security being overly burdensome.
We also have to protect against automated attacks, such as from bots
and credential stuffing. The way our applications work, bots don’t pose
much risk because we have either a client on the customer’s computers
that interacts directly with our apps or a secured web browser that can
only connect to us. There is no way to go straight to one of our apps on
military.
Health

40
the internet. Our patient portal is similar to banks that provide online
banking. The banks have to give users a way to sign in. That’s where
we have a challenge with bot-type attacks. To mitigate that risk, we
use a good web application firewall with advanced bot protection.
We launch an inspection when users update their password to make
sure that they are not using a password that is compromised.

41
41
“You must build security into your application at each step
of production.”
Take security into account from the beginning. Security is not something you add
at the end, like adding a web-based firewall or deciding to encrypt a data store. You
must build security into your application at each step of production.
You must answer many questions before you can implement appropriate levels
of security, such as whether the application is internal or public facing; whether it
will host data; and if so, the sensitivity of that data. You can use security controls
built into the application platform, but you must understand how to implement and
manage those controls.
Another aspect of security is the ability to detect threatening activity in
the environment. A complex, componentized application can generate an
overwhelming amount of activity data that a human cannot analyze. Machine
learning can be a good tool for identifying unusual patterns, and then humans can
look at those patterns and decide if they indicate a threat.
environments.

“Good security goes back to getting the operational
element of your application right early in the
development process.”
Some of the biggest challenges in securing applications result from
misconfigurations, which can create unexpected vulnerabilities and leave your
systems open to attack or accidental compromise. For example, bots can
be a real problem. They are distributed and random, and they can generate
far too much data for humans to decipher. The greatest vulnerability from
bots comes from misconfigured controls that give the bots unauthorized
access to something that can result in serious damage. In addition, users may
inadvertently click something that exposes data or resources.
It is essential to implement application-level firewalls, which examine data flow
from applications and search for suspicious activity. Unlike physical firewalls,
which look primarily at ports and destination Internet Protocol addresses,
application-level firewalls have intelligence to interrogate data flow to detect
unusual activity and keep you safe.
Encryption is also important, and there’s a school of thought that you have to
encrypt absolutely everything. That approach can create problems, however. If
you encrypt absolutely everything, you can’t actually see what’s going on. For
instance, if you have application-level firewalls that use machine learning to
analyze data flow patterns, encrypting everything neutralizes the effectiveness
42

43
of those firewalls. Effective use of encryption requires finding the right
balance between that and other security and monitoring tools.
Security tools generate enormous amounts of log data, especially in
environments that operate at scale. Therefore, you also need machine
learning tools that can monitor and correlate data from security logs.
You must also use certificate-based API communications.
Once you have protected the applications and applied your best
practice, focus on protecting your data, which means having a solid
data platform. You must also plan for a secondary, accessible copy of
your data.
Good security goes back to getting the operational element of your
application right early in the development process. For instance, to
avoid misconfigurations, you must have tight change control that
functions in a highly changeable environment. Build automation into the
change-control process. That way, you can make 1,000 changes a day
if you have to, and those changes will be managed by an automated
change control framework that can’t make a mistake.

44
“You need to assume that parts of your infrastructure are
compromised, and then respond to that by making sure
that even if the first or second layer is compromised, your
data is still not accessible.”
Data security is a challenge for developers because three types of data protection
must take place, and they are handled in different ways. One involves protecting data in
process—that is, data that an application is actively using. This problem can be serious
because a fairly simple tool can monitor what is happening inside an application, and in
a complex environment, any device or endpoint could be compromised.
You must also protect data in transit—that is, data moving between your application
and whatever infrastructure is behind it. Finally, you must protect data at rest—that is,
data stored outside the application (e.g., in a data center or database). Data protection
is further complicated by regulatory requirements, such as the General Data Protection
Regulation, which have specific rules about how you protect data and the controls data
owners must have over their data.
The first step to improving security is to accept the fact that your environment will be
compromised—your network, the server or data center, or the cloud service in which
you operate. How do you ensure that your data is safe when you assume from the
beginning that the environment is compromised? The answer is to encrypt everything.
Many apps do not have their in-process data model encrypted. You need to assume
that parts of your infrastructure are compromised, and then respond to that by making
and secure way.

45
sure that even if the first or second layer is compromised, your data is
still not accessible.
Another critical step is application programming interface (API)
authentication. This step is important because spoofing an API has
become easy. Complete toolkits are available for download so that
malicious hackers do not even have to understand how the API even
works. It’s quite simple to set up a spoof API service. An API responding
to your request doesn’t automatically mean that it is the API you want
to talk to. Before any interchange with an API, verify that it is the API you
actually want to talk to.

46
“Addressing these security challenges requires
complete database visualization. It involves
moving data protection into the application layer.”
Securing the data used in componentized applications is challenging. There
is a perception that cloud vendors use the best patterns to address security
and data breaches, but the reality is that data breaches are a huge risk
and compliance is difficult. Most companies don’t really know what their
vulnerabilities are and what risks they bear. In fact, 72 percent of organizations
use production data in other environments, such as staging areas, where
security policies are often more open because people are using it for testing
and development.
Another example is the global company that provisions everything in Seattle.
From a General Data Protection Regulation perspective, such companies can’t
be sure where their consumer data resides. If they’re running experiments on
large data sets for, say, algorithm development, they’re using customer data.
How do they make sure that the data has been removed? Where are backups
stored, and how are they secured? Or, if they are using data lakes, where is
that data actually being written? Even containers used for temporary storage
become a problem. How do the companies audit those containers? How do
they secure cross-site scripting? How do they address new vulnerabilities?
Addressing these security challenges requires complete database
visualization. It involves moving data protection into the application layer, not
Assured

47
just relying on platform-as-a-service security functions. When moving
data protection into the application layer, you must provide strong
protection for the applications themselves.
Protecting applications is a serious challenge in modern distributed,
serverless, no-ops, high-volume computing environments. With API
proliferation, the monolithic security frameworks designed for older
architectures are no longer adequate. Authentication mechanisms such
as OAuth introduce their own level of risk if you are relying on a third
party for authentication. In addition, there’s the risk of bringing down the
OAuth server with too many token requests.
One approach is to minimize data exposure by using
microcontainerization to create an endpoint that looks like a physical
database but contains only a tiny fraction of the data that has changed.
Still, it’s difficult to ensure security when these instances are short
lived in a no-ops environment where everything is automated. The key
is making sure that you’ve got access to those nodes to see what’s
actually going on. This becomes not only a security and governance
issue but a visibility issue. We use a security platform that provides
real-time adaptive security auditing. It gives much better visibility
into vulnerabilities in real time across every part of the system, and it
provides self-healing capabilities.

48
48
“Different cloud providers configure security controls
differently, . . . so coupling your application’s security too
tightly to a specific cloud provider’s controls will reduce
its portability.”
There are two key aspects to securing applications and data. One is proper
classification of data; the other is proper identification and use of data security
controls.
Many companies don’t understand the risk associated with their data because the
data has not been properly classified. In addition to information that is proprietary
to the business, many different types of personally identifiable information are
subject to regulations regarding its use and protection, regulations related to data
distribution, and data owners’ approvals for use. To secure that data, companies
must understand the nature of the data they possess and the rules that govern it
so that they can apply the right security controls.
Many infrastructure-based security controls are available to protect your data, but
unless you have relevant policies governing acceptable risk to the organization,
you don’t know which of those controls to employ. Cloud service providers offer
security controls and the means to monitor and manage them. Different cloud
providers configure security controls differently, however, so coupling your
application’s security too tightly to a specific cloud provider’s controls will reduce
its portability. That said, building your own security controls into the application
can be costly, so there are trade-offs.
SourceConnecte

49
These considerations apply to the use of application programming
interfaces (APIs) that integrate your application services. If
you use an API across your environment, you may need to
determine whether it contains specific data controls. If it doesn’t,
then you may need to add those controls. Ultimately, the data
security controls required are dictated by the organizational risk
management process and policies.

50
50
“If private APIs are involved, you want to be able
to authenticate and approve the actual user of the
API.”
The greatest challenge in securing data is understanding the types of data you
will be receiving because the type of data your application handles determines
the type of security you must have in place. An application should have a data
model behind it that applies classifications to stored data. For instance, if you are
taking online payments that involve collecting credit card or bank account details,
that information is classified and must be stored in a Payment Card Industry Data
Security Standard–compliant manner. By classifying data, you can then apply
relevant privacy controls, data loss controls, encryption, and security.
With API-centric componentized applications, it’s important to secure private
API communications. Typically, you would use public APIs to return public data,
but if private APIs are involved, you want to be able to authenticate and approve
the actual user of the API. Doing so requires a process for providing the relevant
authentication keys for something that’s coming into a private API. These
authentication keys could be licensed, or they could have an expiry date so that
when they expire, the user or process must re-sign to continue accessing the API.
Activity monitoring is another security measure used to analyze normal operations
and detect unusual activities that could indicate that someone is trying to inject
code into your application. You must consider all these security measures during
the application design stage. If your requirements call for a secure service, you
must fully understand your data and the way in which your transactions will be

51
authenticated. You must understand the nature of the traffic your
application will generate and how to control it. You must plan for
the possibility that someone will try to perform some kind of code
injection on your services and have a way to isolate such code.
You’ve got to design all those elements up front, and you must
have a way to test them. It’s about designing for security.

52
RAPID TROUBLESHOOTING
CHAPTER 4
Maintaining application performance and reliability depends on the ability to identify problems and deploy
fixes quickly. As applications become increasingly complex, componentized, and distributed, troubleshooting
becomes more difficult. To find out how the experts approach troubleshooting in complex application
environments, we asked them the following question:
How does visibility across systems factor into troubleshooting a problem quickly?

53
“The more microservices you implement, the more
careful you need to be with the state of operations
in your production environment because you
introduce many changes more frequently.”
The more microservices you implement, the more careful you need to be
with the state of operations in your production environment because you
will be introducing many changes more frequently. You must have tools
that give you visibility into what is actually happening.
I have found it important to have visibility into all the endpoints and
infrastructure in use, and to set alerts that notify when something
is not right. This visibility is important for production debugging, but
the goal should be to find problems before they reach production.
Current technology provides the capability to run multiple versions
of microservices at the same time. Best practice is to do so by
implementing a canary process (like in the coal mines of old times). When
a microservice is ready to go into production, it is released to a small
subset of users while the existing application service still handles the
primary load. Taking this approach enables the dev-ops teams to compare
the two versions functionally. Once the canary release is fully burned in
and tested, it can be released into general production. The key to this
process is monitoring and visibility.
InnerWorkings.

54
54
“When you have visibility into your entire distributed
computing stack, you can quickly pinpoint problems,
reducing the time needed to resolve an incident.”
Visibility into the whole application stack is essential for facilitating quick and
efficient troubleshooting. This is especially true in modern architectures with
distributed applications based on microservices and containers running in
different places.
The first step in troubleshooting is finding the problem. Troubleshooting in a
distributed computing environment is different from troubleshooting a monolithic
legacy application, where everything is in one place. When you have visibility
into your entire distributed computing stack, you can quickly pinpoint problems,
reducing the time needed to resolve an incident.
Machine learning plays an important role in troubleshooting componentized
applications because of its ability to monitor and analyze large amounts of
activity data. Machine learning can proactively identify risk or potential future
problems before a human can detect them because of its scalability and use in
capacity management. This technology can help correlate usage patterns with
infrastructure needs and in that way reduce potential load and avert bottlenecks
that may cause problems in the future.
environments.

55
That said, humans still perform most high-level troubleshooting
tasks. Machine learning can quickly pinpoint a risk, problem,
or threat, but it takes a human to troubleshoot multiplatform
technology. Machine learning is important, but it’s also important
to have an operations team that understands the application setup
and platform technology. People are good at quickly spotting
operations that are not going well.

“Application performance monitoring is vital for
troubleshooting, especially when you’re dealing with an
application that relies on multiple clouds, multiple data
centers, complex infrastructure, different networks, and
different types of code.”
Visibility is hugely important. Ideally, you would build application performance
monitoring capabilities into your code so that you can see end-to-end
transactions. Such monitoring becomes even more critical in a large
microservices environment.
Application performance monitoring is vital for troubleshooting, especially
when you’re dealing with an application that relies on multiple clouds, multiple
data centers, complex infrastructure, different networks, and different types
of code. If you are creating a revenue-generating app and you’ve got problems
during the middle of the day, you’ve got absolutely no chance of being able to
resolve them in a timely manner.
56

57
“[Machine learning] adds value in environments where
there are many data points and it’s not clear which data
points influence which other data points.”
There are four layers to effective troubleshooting:
• Information that you receive. Build a layer of communication that helps you
receive essential diagnostic information, not just someone creating a ticket. You
need the ability to pull a status record or a mechanism for telling the app to send a
compilation of all known information relevant to an incident.
• Understanding what happened. The information you receive is useless if you do
not understand it. You need data in a digestible form, and the team must have the
skills to understand what it means.
• Operational circumstances. This layer can pose a significant challenge for
developers because they will never have the exact set of data points or the exact
number of transactions that take place in a live environment going on in their testing
environment.
• Access to code. Sometimes, particularly in larger companies, developers or
support teams do not always have technical access at the level they need to be
able to feed the diagnostic and test data into the system to see what is actually
happening.
and secure way.

58
It’s important to plan for these four aspects of troubleshooting, to
develop critical thinking within your team, and to have good diagnostic
tools. Artificial intelligence and machine learning tools are essential
for troubleshooting, particularly in complex environments with a lot of
distributed computing activity. Machine learning can process much
more data than a person in a fraction of the time, and it can evaluate
and recognize abnormal patterns without emotional bias. It adds value
in environments where there are many data points and it’s not clear
which data points influence which other data points.
Another advantage of machine learning is its ability to run high-speed,
repetitive testing. In a dynamic, connected environment, you cannot
assume that because something worked at a certain point, it will work
at all points. A trained machine learning engine can perform 150,000
tests in under two seconds, where a human being would need two
minutes just to set up the parameters for the test. These capabilities
are valuable to human analysts, who are then free to interpret the
anomalous patterns and find root causes.

59
“If something is not working correctly, we need to
be able to detect whether this is actually an issue
with our system or a version of something we put
into the real world.”
Visibility into application performance is critical to determining whether the
application is running well and which corrective measures must be taken if it is
not. If something is not working correctly, we need to be able to detect whether
this is actually an issue with our system or a version of something we put into
the real world.
The challenge is that cloud and public networking platforms are built with
privacy by design. Certain kinds of information, such as crash analytics from
phone network operators, is simply unavailable from the service provider
largely because of privacy and security concerns.
This restriction can be a challenge for certain kinds of applications. For
instance, we are currently conducting production testing for a phone-based
contact tracing application used to monitor the spread of COVID-19. To
overcome “privacy by design,” we look at what is happening at endpoints. We
use large amounts of endpoint machine data to perform root cause analysis
and pinpoint failure—a standard feature in most AI operations or intelligent
operation platforms. Through endpoint data analysis, we can correlate specific
behaviour problems to networks and application versions, and we see it
happen in real time with real users. Ultimately, you want the ability to measure
Assured

60
behaviour based on a release of the application, and then compare a
limited release to performance models before deciding whether to roll
the version out more widely.
We have to trust that the data coming through is actually correct and
that the predictive models we are using and the relationships we are
predicting between people interacting with each other are good.

61
61
“Knowing what is normal comes from building
standardization into the application infrastructure,
application design, and deployment.”
Visibility is required to show you what is and is not normal in an application
environment. Knowing what is normal comes from building standardization into
the application infrastructure, application design, and deployment.
Without standardization, you don’t know what normal is. When something
happens that you’ve never seen before, you have to decide if it is something that
should happen. Because you don’t know what should happen, evaluating that
event takes time. If you have a standardized environment, however, and you look
at that environment for a week, you know what’s normal for that environment. If
something abnormal occurs, it will be obvious. That is visibility.
A standard application infrastructure also makes machine learning tools more
powerful for troubleshooting. Complex application environments generate huge
amounts of log and tracking data—more data than humans can or should have
to process, especially when most of that data describes normal application
operations. Humans are good at solving abstract problems. They are great
at using their brain power to analyze unique observations. That is where you
need to focus human attention. You do not want to waste human brainpower
troubleshooting what is normal.
SourceConnecte

62
Machine learning can quickly identify something that is not normal.
A major prerequisite for the use of machine learning, however, is
the broad adoption and consistent implementation of standardized
application design, security policies, and controls. Logs and
tracking data provide zero insight unless you use them to enforce a
standardized policy.

63
63
“If something breaks, the application should be coded
to fail gracefully and provide the relevant debugging
information as part of its output. This behavior should be
an immutable part of your application framework.”
Effective troubleshooting depends on being able to see what is happening inside
your application. To do that, you must build in proper error handling. If something
fails in your application, it should fail gracefully and provide clear error messaging
that displays the data element involved in the failure.
Such a capability requires building functionality into your application framework
to monitor the entire transaction life cycle, especially if microservices with
complex dependencies are involved. You can embed such functionality through
an agent that monitors everything that happens throughout the stack. You
want to understand the journey of a transaction. Then, if something breaks, the
application should be coded to fail gracefully and provide the relevant debugging
information as part of its output. This behavior should be an immutable part of
your application framework.
Machine learning can also be a useful tool for analyzing large volumes of
operational data to detect problems or security issues. Machine learning is best
at detecting trends that may point to a problem or an opportunity to optimize an
application. Invariably, though, humans have to get involved because machine
learning cannot provide adaptive solutions. When a machine learning algorithm
encounters a scenario it does not know how to handle, it alerts a human, who can
perform an evaluation and decide how best to handle that scenario. The human’s

64
decision goes into the machine learning feedback loop so that
over time, the machine is able to do more and pass less off to the
human.
Machine learning is just an application that you provide with
operational parameters. It is only as good as what you tell it to do.
It will learn, but the learning needs validation.

8 Experts on Flawless App Delivery

More Related Content

What's hot

Similar to 8 Experts on Flawless App Delivery

More from Mighty Guides, Inc.

Recently uploaded

8 Experts on Flawless App Delivery