AGPIAL A Good Person Is Always Learning.: Recent Episodes
AGPIAL Phillip J. Murphy
Audio Books generated from PDF documentation related to various subjects. Support this podcast: https://anchor.fm/agpial/support
Chapter Summary
This chapter discussed some of the concepts and goals of primary and intermediate flight training. It identified and provided
an explanation of regulatory requirements and the roles of the various entities involved. It also offered recommended techniques to
be practiced and refined to develop the knowledge, proficiency, and safe habits of a competent pilot.
--- Support this podcast: https://podcasters.spotify.com/pod/show/agpial/support
Integration today No application is an island. To get the most from the software you build or buy, you need to connect it to other software. This means that effective application integration is essential for just about every organization. Sometimes, all you need to do is connect one application directly to another. More often, though, application integration means connecting multiple independent systems, often in complex ways. This is why organizations commonly rely on specialized integration platforms that provide the services needed to do this. Like so much else today, those platforms have moved from on-premises datacenters into the public cloud. Rather than use traditional integration technologies such as BizTalk Server, more and more organizations are using integration Platform as a Service (iPaaS) solutions, i.e., cloud-based integration platforms To meet this need, Microsoft provides Azure Integration Services. This iPaaS solution is a set of cloud services for mission critical enterprise integration. To achieve this goal, these services provide the four core technologies required for cloud-based integration
Support this podcast: https://anchor.fm/agpial/support
Chapter Summary.
Every pilot is an energy manager—managing energy in the form of altitude and airspeed from takeoff to landing.
Proper energy management is essential for performing any maneuver as well as for attaining and maintaining desired vertical flightpath and airspeed profiles in everyday flying.
It is also critical to flight safety since mistakes in managing energy state can contribute to loss of control inflight (LOC-I), controlled flight into terrain (CFIT), and approach and landing accidents.
The objectives of this chapter are for pilots to: 1) gain an understanding of basic energy management concepts; 2) learn the energy role of the controls for managing the airplane’s energy state; and 3) develop the ability to identify, assess, and mitigate risks associated with failure to manage the airplane’s energy state.
Chapter 4: Energy Management: Mastering Altitude and Airspeed Control
Introduction.
This chapter is all about managing the airplane’s altitude and airspeed using an energy-centered approach.
Energy management can be defined as the process of planning, monitoring, and controlling altitude and airspeed targets in relation to the airplane’s energy state in order to:
-
Attain and maintain desired vertical flightpath-airspeed profiles.
-
Detect, correct, and prevent unintentional altitude-airspeed deviations from the desired energy state.
-
Prevent irreversible deceleration and/or sink rate that results in a crash.
Importance of Energy Management.
Learning to manage the airplane’s energy in the form of altitude and airspeed is critical for all new pilots.
Energy management is essential for effectively achieving and maintaining desired vertical flight path and airspeed profiles, (e.g., constant airspeed climb) and for transitioning from one profile to another during flight, (e.g., leveling off from a descent).
Proper energy management is also critical to flight safety.
Mistakes in managing the airplane’s energy state can be deadly.
Mismanagement of mechanical energy (altitude and/or airspeed) is a contributing factor to the three most common types of fatal accidents in aviation: loss of control in-flight (LOC-I), controlled flight into terrain (CFIT), and approach-and-landing accidents.
Thus, pilots need to have:
-
An accurate mental model of the airplane as an energy system.
-
The competency to effectively coordinate control inputs to achieve and maintain altitude and airspeed targets.
-
The ability to identify, assess, and mitigate the risks associated with mismanagement of energy.
Viewing the Airplane as an Energy System.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Chapter Summary.
The four fundamental maneuvers of straight-and-level flight, turns, climbs, and descents are the foundation of basic airmanship.
Effort and continued practice are required to master the fundamentals.
It is important that a pilot consider the six motions of flight: bank, pitch, yaw and horizontal, vertical, and lateral displacement.
In order for an airplane to fly from one location to another, it pitches, banks, and yaws while it moves over and above, in relationship to the ground, to reach its destination.
The airplane should be treated as an aerodynamic vehicle that is subject to rigid aerodynamic laws.
A pilot needs to understand and apply the principles of flight in order to control an airplane with the greatest margin of mastery and safety.
Chapter 3: Basic Flight Maneuvers
Introduction.
Airplanes operate in an environment that is unlike an automobile.
Drivers tend to drive with a fairly narrow field of view and focus primarily on forward motion.
Beginning pilots tend to practice the same.
Flight instructors face the challenge of teaching beginning pilots about attitude awareness; which requires understanding the motions of flight.
An airplane rotates in bank, pitch, and yaw while also moving horizontally, vertically, and laterally.
The four fundamentals (straight-and-level flight, turns, climbs, and descents) are the principal maneuvers that control the airplane through the six motions of flight.
The Four Fundamentals.
To master any subject, one should first master the fundamentals.
For flying, this includes straight-and-level flight, turns, climbs, and descents.
All flying tasks are based on these maneuvers, and an attempt to move on to advanced maneuvers prior to mastering the four fundamentals hinders the learning process.
Consider the following: a takeoff is a combination of a ground roll, which may transition to a brief period of straight-and-level flight, and a climb.
After-departure includes the climb and turns toward the first navigation fix and is followed by straight-and-level flight.
The preparation for landing at the destination may include combinations of descents, turns, and straight-and-level flight.
In a typical general aviation (GA) airplane, the final approach ends with a transition from descent to straight-and-level while slowing for the touchdown and ground roll.
The flight instructor needs to impart competent knowledge of these basic flight maneuvers so that the beginning pilot is able to combine them at a performance level that at least meets the Federal Aviation Administration (FAA) Airman Certification Standards (ACS) or Practical Test Standards (PTS).
As the beginning pilot progresses to more complex flight maneuvers, any deficiencies in the mastery of the four fundamentals are likely to become barriers to effective and efficient learning.
Effect and Use of Flight Controls.
The airplane flies in an environment that allows it to travel up and down as well as left and right.
Note that movement up or down depends on the flight conditions.
If the airplane is right-side up relative to the horizon, forward control stick or wheel (elevator control) movement will result in a loss of altitude.
If the same airplane is upside-down relative to the horizon that same forward control movement will result in a gain of altitude.
The following discussion considers the pilot's frame of reference with respect to the flight controls.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Chapter Summary.
This chapter places emphasis on determining the airworthiness of the airplane, preflight visual inspection, managing risk and pilot- available resources, safe surface-based operations, and the adherence to and proper use of the AFM/POH and checklists.
The pilot should ensure that the airplane is in a safe condition for flight, and it meets all the regulatory requirements of 14 CFR part 91.
A pilot also needs to recognize that flight safety includes proper flight preparation and having the experience to manage the risks associated with the expected conditions.
An effective and continuous assessment and mitigation of the risks and appropriate utilization of resources goes a long way provided the pilot honestly evaluates their ability to act as PIC.
Chapter 2: Ground Operations
Introduction.
Experienced pilots place a strong emphasis on ground operations as this is where safe flight begins and ends.
They know that hasty ground operations diminish their margin of safety.
A smart pilot takes advantage of this phase of flight to assess various factors including the regulatory requirements, the pilot’s readiness for pilot-in-command (PIC) responsibilities, the airplane’s condition, the flight environment, and any external pressures that could lead to inadequate control of risk.
Flying an airplane presents many new responsibilities not required for other forms of transportation.
Focus is often placed on the flying portion itself with less emphasis placed on ground operations.
However pilots need to allow time for flight preparation.
Situational awareness begins during preparation and only ends when the airplane is safely and securely returned to its tie-down or hangar, or if a decision is made not to go.
This chapter covers the essential elements for the regulatory basis of flight including: 1.
An airplane’s airworthiness requirements, 2.
Important inspection items when conducting a preflight visual inspection, 3.
Managing risk and resources, and 4.
Proper and effective airplane surface movements using the AFM/POH and airplane checklists.
Preflight Assessment of the Aircraft.
The visual preflight assessment mitigates airplane flight hazards.
The preflight assessment ensures that any aircraft flown meets regulatory airworthiness standards and is in a safe mechanical condition prior to flight.
Per 14 CFR part 3, section 3.5(a), the term “airworthy” means that the aircraft conforms to its type design and is in condition for safe operation.
The owner/operator is primarily responsible for maintenance, but in accordance with 14 CFR part 91, section 91.7(a) and (b) no person may operate a civil aircraft unless it is in an airworthy condition and the pilot in command of a civil aircraft is responsible for determining whether the aircraft is in condition for safe flight.
The pilot's inspection should involve the following:
-
Inspecting the airplane’s airworthiness status.
-
Following the AFM/POH to determine the required items for visual inspection.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Chapter Summary.
This chapter discussed some of the concepts and goals of primary and intermediate flight training.
It identified and provided an explanation of regulatory requirements and the roles of the various entities involved.
It also offered recommended techniques to be practiced and refined to develop the knowledge, proficiency, and safe habits of a competent pilot.
Chapter 1: Introduction to Flight Training
Introduction.
The overall purpose of primary and intermediate flight training, as outlined in this handbook, is the acquisition and honing of basic airmanship skills.
Airmanship is a broad term that includes a sound knowledge of and experience with the principles of flight; the knowledge, experience, and ability to operate an aircraft with competence and precision both on the ground and in the air; and the application of sound judgment that results in optimal operational safety and efficiency.
Learning to fly an aircraft has often been compared to learning to drive an automobile.
This analogy is misleading.
Since aircraft operate in a three- dimensional environment, they require a depth of knowledge and type of motor skill development that is more sensitive to this situation, such as:
Coordination–the ability to use the hands and feet together subconsciously and in the proper relationship to produce desired results in the airplane.
Timing–the application of muscular coordination at the proper instant to make flight, and all maneuvers, a constant, smooth process.
Control touch–the ability to sense the action of the airplane and knowledge to determine its probable actions immediately regarding attitude and speed variations by sensing the varying pressures and resistance of the control surfaces transmitted through the flight controls.
Speed sense–the ability to sense and react to reasonable variations of airspeed.
An accomplished pilot demonstrates the knowledge and ability to:
Assess a situation quickly and accurately and determine the correct procedure to be followed under the existing circumstance.
Predict the probable results of a given set of circumstances or of a proposed procedure.
Exercise care and due regard for safety.
Accurately gauge the performance of the aircraft.
Recognize personal limitations and limitations of the aircraft and avoid exceeding them.
Identify, assess, and mitigate risk on an ongoing basis.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Domain-driven design
https://amzn.to/3ERxcSZ
(paid link) As an Amazon Associate I earn from qualifying purchases.
Domain-driven design Domain-driven design (DDD) is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain.
For example, if a software processes loan applications, it might have classes such as LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.
DDD connects the implementation to an evolving model.
Domain-driven design is predicated on the following goals: placing the project's primary focus on the core domain and domain logic; basing complex designs on a model of the domain; initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Criticisms of domain-driven design argue that developers must typically implement a great deal of isolation and encapsulation to maintain the model as a pure and helpful construct.
While domain- driven design provides benefits such as maintainability, Microsoft recommends it only for complex domains where the model provides clear benefits in formulating a common understanding of the domain.
The term was coined by Eric Evans in his book of the same title.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
https://amzn.to/3zASC2N
(paid link) As an Amazon Associate I earn from qualifying purchases.
The teaching profession is under siege.
Working hours for teachers are increasing as student needs become more complex and administrative and paperwork burdens increase.
According to a recent McKinsey survey, conducted in a research partnership with Microsoft, teachers are working an average of 50 hours a week1—a number that the Organisation for Economic Co-operation and Development Teaching and Learning International Survey suggests has increased by 3 percent over the past five years.2 While most teachers report enjoying their work, they do not report enjoying the late nights marking papers, preparing lesson plans, or filling out endless paperwork.
Burnout and high attrition rates are testaments to the very real pressures on teachers.
In the neediest schools in the United States, for example, teacher turnover tops 16 percent per annum.3 In the United Kingdom, the situation is even worse, with 81 percent of teachers considering leaving teaching altogether because of their workloads.4 Further disheartening to teachers is the news that some education professors have even gone so far as to suggest that teachers can be replaced by robots, computers, and artificial intelligence (AI).5 Our research offers a glimmer of hope in an otherwise bleak landscape.
The McKinsey Global Institute’s 2018 report on the future of work suggests that, despite the dire predictions, teachers are not going away any time soon.
In fact, we estimate the school teachers will grow by 5 to 24 percent in the United States between 2016 and 2030.
For countries such as China and India, the estimated growth will be more than 100 percent.6 Moreover, our research suggests that, rather than replacing teachers, existing and emerging technologies will help them do their jobs better and more efficiently.
Our current research suggests that 20 to 40 percent of current teacher hours are spent on activities that could be automated using existing technology.
That translates into approximately 13 hours per week that teachers could redirect toward activities that lead to higher student outcomes and higher teacher satisfaction.
In short, our research suggests that existing technology can help teachers reallocate 20 to 40 percent of their time to activities that support student learning.
Further advances in technology could push this number higher and result in changes to classroom structure and learning modalities, but are unlikely to displace teachers in the foreseeable future.
Many of the attributes that make good teachers great are the very things that AI or other technology fails to emulate: inspiring students, building positive school and class climates, resolving conflicts, creating connection and belonging, seeing the world from the perspective of individual students, and mentoring and coaching students.
These things represent the heart of a teacher’s work and cannot— and should not—be automated.
Make no mistake, the value of a good education starts early and lasts a lifetime.
Research suggests that simply having an effective kindergarten teacher can affect the likelihood of a student completing college thus boosting their lifetime earnings by about $320,000.7 Technology, when used correctly, can facilitate good teaching, but it will never replace teachers.
In the remainder of this article, we will outline how teachers spend their time today, how technology can help to save teacher time, and where that additional time might go.
Note that we are intentionally focused on the impact of technology on teacher time.
In future articles we will address its broader impact on student learning.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Model Based Systems Engineering (MBSE) on AWS: From Migration to Innovation
https://amzn.to/3lQJ6E5
(paid link) As an Amazon Associate I earn from qualifying purchases.
Abstract.
Model Based Systems Engineering (MBSE) is a modern approach to the conventional practice of document-based systems engineering.
MBSE benefits from modern cloud computing technologies, microservices, AI/ML, advanced analytics and others.
These technologies not only enable broad adoption of MBSE by engineering organizations, but also go beyond the current prospects of MBSE and bring innovation, flexibility, scalability and cost optimization.
MBSE has been recently adopted by aerospace, energy, and automotive customers and growing in other industries where complex products - made of multitude of engineering disciplines and collaboration - are required to design, build, test, sustain and monitor the whole product lifecycle through their lifecycle.
AWS provides both building block technologies and solutions tailored to your needs.
This whitepaper addresses both MBSE developers who develop MBSE technologies and MBSE users who use MBSE tools.
It also provides introductory information about MBSE and its challenges for newcomers to this technology.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
https://amzn.to/3lNebZm
(paid link) As an Amazon Associate I earn from qualifying purchases.
Welcome to the AGPIAL audiobook production of
McKinsey and Company.
Technology, Media and Telecommunications Practice's article.
SaaS and the Rule of 40.
Don't forget to like and subscribe.
Thank you, Now let's go !
Keys to the critical value creation metric.
Investors reward SaaS companies that hit this operating performance marker, yet a surprisingly small number have been able to do so.
Here’s how more can follow their industry leaders’ example.
by Paul Roche and Sid Tandon
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
SaaS Lens AWS Well-Architected Framework
https://amzn.to/39rBwd6
(paid link) As an Amazon Associate I earn from qualifying purchases.
Abstract.
This paper describes the SaaS Lens for the AWS Well-Architected Framework, which enables customers to review and improve their cloud-based architectures and better understand the business impact of their design decisions.
We address general design principles as well as specific best practices and guidance in five conceptual areas that we define as the pillars of the Well-Architected Framework.
Introduction.
The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building systems on AWS.
By using the Framework you will learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud.
It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement.
We believe that having well-architected systems greatly increases the likelihood of business success.
In this “Lens” we focus on how to design, deploy, and architect your multi-tenant software as a service (SaaS) application workloads in the AWS Cloud.
For brevity, we have only covered details from the Well- Architected Framework that are specific to SaaS workloads.
You should still consider best practices and questions that have not been included in this document when designing your architecture.
We recommend that you read the AWS Well-Architected Framework whitepaper.
This document is intended for those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members.
After reading this document, you will understand AWS best practices and strategies to use when designing architectures for SaaS applications.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Serverless Architectures with AWS Lambda AWS Whitepaper.
https://amzn.to/2XKjsZp
(paid link) As an Amazon Associate I earn from qualifying purchases.
Abstract.
Since its introduction at AWS re:Invent in 2014, AWS Lambda has continued to be one of the fastest growing AWS services.
With its arrival, a new application architecture paradigm was created—referred to as serverless.
AWS now provides a number of different services that allow you to build full application stacks without the need to manage any servers.
Use cases like web or mobile backends, real-time data processing, chatbots and virtual assistants, Internet of Things (IoT) backends, and more can all be fully serverless.
For the logic layer of a serverless application, you can execute your business logic using AWS Lambda.
Developers and organizations are finding that AWS Lambda is enabling much faster development speed and experimentation than is possible when deploying applications in a traditional server-based environment.
This whitepaper is meant to provide you with a broad overview of AWS Lambda, its features, and a slew of recommendations and best practices for building your own serverless applications on AWS.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Security Overview of AWS Lambda AWS Whitepaper
https://amzn.to/3zpABEs
(paid link) As an Amazon Associate I earn from qualifying purchases.
Abstract.
This whitepaper presents a deep dive of the AWS Lambda service through a security lens.
It provides a well-rounded picture of the service, which is useful for new adopters, and deepens understanding of Lambda for current users.
The intended audience for this whitepaper is Chief Information Security Officers (CISOs), information security engineers, enterprise architects, compliance teams, and any others interested in understanding the underpinnings of AWS Lambda.
Introduction.
Today, more workloads are using AWS Lambda to achieve scalability, performance, and cost efficiency, without managing the underlying infrastructure.
These workloads scale to thousands of concurrent requests per second.
Lambda one of the many important services that is offered by AWS today.
Lambda is used by hundreds of thousands of Amazon Web Services (AWS) customers to serve trillions of requests every month.
Lambda is suitable for mission critical applications in many industries.
A broad variety of customers, from media and entertainment to financial services and other regulated industries, take advantage of Lambda.
These customers decrease time to market, optimize costs, and improve agility by focusing on what they do best: running their business.
The managed runtime environment model enables Lambda to manage much of the implementation details of running serverless workloads.
This model further reduces the attack surface while making cloud security simpler.
This whitepaper presents the underpinnings of that model, along with best practices, to developers, security analysts, security and compliance teams, and other stakeholders.
00:00:00 Welcome
00:00:14 Abstract
00:00:43 Introduction
00:01:56 About AWS Lambda
00:03:32 Benefits of Lambda
00:05:54 Cost for running Lambda-based applications
00:06:20 The Shared Responsibility Model
00:07:00 Lambda Functions and Layers
00:08:23 Lambda Invoke Modes
00:11:40 Lambda Executions
00:13:03 Lambda execution environments
00:16:00 Execution role
00:17:14 Lambda MicroVMs and Workers
00:20:15 Lambda Isolation Technologies
00:22:07 Storage and state
00:24:29 Runtime Maintenance in Lambda
00:27:00 Monitoring and Auditing Lambda Functions
00:29:16 Architecting and Operating Lambda Functions
00:30:41 Lambda and Compliance
00:31:55 Lambda Event Sources
00:33:32 Conclusion
00:34:09 Contributors
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Serverless Applications Lens AWS Well-Architected Framework
https://amzn.to/3znWIvg
(paid link) As an Amazon Associate I earn from qualifying purchases.
Abstract.
This document describes the Serverless Applications Lens for the AWS Well-Architected Framework.
The document covers common serverless applications scenarios and identifies key elements to ensure that your workloads are architected according to best practices.
Introduction.
The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building systems on AWS.
By using the Framework, you will learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud.
It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement.
We believe that having well-architected systems greatly increases the likelihood of business success.
In this “Lens” we focus on how to design, deploy, and architect your serverless application workloads in the AWS Cloud.
For brevity, we have only covered details from the Well-Architected Framework that are specific to serverless workloads.
You should still consider best practices and questions that have not been included in this document when designing your architecture.
We recommend that you read the AWS Well-Architected Framework whitepaper.
This document is intended for those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members.
After reading this document, you will understand AWS best practices and strategies to use when designing architectures for serverless applications.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Reliability Pillar AWS Well-Architected Framework.
https://amzn.to/3zk4UwC
(paid link) As an Amazon Associate I earn from qualifying purchases.
Abstract.
The focus of this paper is the reliability pillar of the AWS Well-Architected Framework.
It provides guidance to help customers apply best practices in the design, delivery, and maintenance of Amazon Web Services (AWS) environments.
Introduction.
The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building workloads on AWS.
By using the Framework you will learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective workloads in the cloud.
It provides a way to consistently measure your architectures against best practices and identify areas for improvement.
We believe that having well-architected workload greatly increases the likelihood of business success.
The AWS Well-Architected Framework is based on five pillars:
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization This paper focuses on the reliability pillar and how to apply it to your solutions.
Achieving reliability can be challenging in traditional on-premises environments due to single points of failure, lack of automation, and lack of elasticity.
By adopting the practices in this paper you will build architectures that have strong foundations, resilient architecture, consistent change management, and proven failure recovery processes.
This paper is intended for those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members.
After reading this paper, you will understand AWS best practices and strategies to use when designing cloud architectures for reliability.
This paper includes high-level implementation details and architectural patterns, as well as references to additional resources.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Cost Optimization Pillar AWS Well-Architected Framework
https://amzn.to/2VLUhon
(paid link) As an Amazon Associate I earn from qualifying purchases.
Welcome to the AGPIAL audiobook production of
Cost Optimization Pillar AWS Well-Architected Framework.
Don't forget to like and subscribe.
Thank you, Now let's go !
Abstract.
This whitepaper focuses on the cost optimization pillar of the Amazon Web Services (AWS) Well- Architected Framework.
It provides guidance to help customers apply best practices in the design, delivery, and maintenance of AWS environments.
A cost-optimized workload fully utilizes all resources, achieves an outcome at the lowest possible price point, and meets your functional requirements.
This whitepaper provides in-depth guidance for building capability within your organization, designing your workload, selecting your services, configuring and operating the services, and applying cost optimization techniques.
Introduction.
The AWS Well-Architected Framework helps you understand the decisions you make while building workloads on AWS.
The Framework provides architectural best practices for designing and operating reliable, secure, efficient, and cost-effective workloads in the cloud.
It demonstrates a way to consistently measure your architectures against best practices and identify areas for improvement.
We believe that having well-architected workloads greatly increases the likelihood of business success.
The framework is based on five pillars:
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization
This paper focuses on the cost optimization pillar, and how to architect workloads with the most effective use of services and resources, to achieve business outcomes at the lowest price point.
You’ll learn how to apply the best practices of the cost optimization pillar within your organization.
Cost optimization can be challenging in traditional on-premises solutions because you must predict future capacity and business needs while navigating complex procurement processes.
Adopting the practices in this paper will help your organization achieve the following goals:
Practice Cloud Financial Management
Expenditure and usage awareness
Cost effective resources
Manage demand and supply resources
Optimize over time
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Performance Efficiency Pillar AWS Well-Architected Framework. AGPIAL Audiobook
https://amzn.to/2VKRZpz(paid link)
As an Amazon Associate I earn from qualifying purchases.
Thank you.
Abstract.
This whitepaper focuses on the performance efficiency pillar of the AWS Well-Architected Framework.
It provides guidance to help customers apply best practices in the design, delivery, and maintenance of AWS environments.
The performance efficiency pillar addresses best practices for managing production environments.
This paper does not cover the design and management of non-production environments and processes, such as continuous integration or delivery.
Introduction.
The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building workloads on AWS.
Using the Framework helps you learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective workloads in the cloud.
The Framework provides a way for you to consistently measure your architectures against best practices and identify areas for improvement.
We believe that having well-architected workloads greatly increases the likelihood of business success.
The framework is based on five pillars:
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization This paper focuses on applying the principles of the performance efficiency pillar to your workloads.
In traditional, on-premises environments, achieving high and lasting performance is challenging.
Using the principles in this paper will help you build architectures on AWS that efficiently deliver sustained performance over time.
This paper is intended for those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members.
After reading this paper, you’ll understand AWS best practices and strategies to use when designing a performant cloud architecture.
This paper does not provide implementation details or architectural patterns.
However, it does include references to appropriate resources.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Operational Excellence Pillar AWS Well-Architected Framework
https://amzn.to/394m8Ds
(paid link) As an Amazon Associate I earn from qualifying purchases.
Operational Excellence Pillar AWS Well-Architected Framework
Introduction.
The AWS Well-Architected Framework helps you understand the benefits and risks of decisions you make while building workloads on AWS.
By using the Framework you will learn operational and architectural best practices for designing and operating reliable, secure, efficient, and cost-effective workloads in the cloud.
It provides a way to consistently measure your operations and architectures against best practices and identify areas for improvement.
We believe that having Well-Architected workloads that are designed with operations in mind greatly increases the likelihood of business success.
The framework is based on five pillars:
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization This paper focuses on the operational excellence pillar and how to apply it as the foundation of your well-architected solutions.
Operational excellence is challenging to achieve in environments where operations is perceived as a function isolated and distinct from the lines of business and development teams that it supports.
By adopting the practices in this paper you can build architectures that provide insight to their status, are enabled for effective and efficient operation and event response, and can continue to improve and support your business goals.
This paper is intended for those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members.
After reading this paper, you will understand AWS best practices and the strategies to use when designing cloud architectures for operational excellence.
This paper does not provide implementation details or architectural patterns.
However, it does include references to appropriate resources for this information.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
The Scrum Guide.
The Definitive Guide to Scrum, The Rules of the Game.
Purpose of the Scrum Guide.
We developed Scrum in the early 1990s.
We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum.
We have evolved the Guide since then through small, functional updates.
Together, we stand behind it.
The Scrum Guide contains the definition of Scrum.
Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum.
Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
We follow the growing use of Scrum within an ever-growing complex world.
We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots.
As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work.
We use the word “developers” in Scrum not to exclude, but to simplify.
If you get value from Scrum, consider yourself included.
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised.
Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses.
Such tactics for using within the Scrum framework vary widely and are described elsewhere.
Ken Schwaber & Jeff Sutherland November 2020
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
Adopting Amazon Web Services (AWS) presents many benefits, such as increased business agility and flexibility, as well as reduced costs.
However, in order to fully realize these benefits your staff may need to acquire new skills and create or update core processes.
Doing so can maximize the business value and minimize the business risks of cloud adoption.
The AWS Cloud Adoption Framework (AWS CAF) helps organizations understand how cloud adoption transforms the way they work, and it provides structure to identify and address gaps in skills and processes.
Applying the AWS CAF in your organization results in an actionable plan with defined work streams that can guide your organization’s path to cloud adoption.
This framework leverages our experiences and best practices in assisting organizations around the world with their cloud adoption journey.
Introduction
Cloud computing introduces a significant shift in how technology is obtained, used, and managed.
It also shifts how organizations budget and pay for technology services.
Cloud computing benefits organizations by giving them the ability to trade capital expense for variable expense, gain advantage from massive economies of scale, make agile capacity decisions, increase business speed and agility, stop spending money running and maintaining data centers, and go global in minutes.
With Amazon Web Services (AWS) your organization can immediately provision the compute, storage, network, and database resources needed for any project.
These resources launch and are ready for use by your project team within minutes.
The environment can be reconfigured easily, updated quickly, scaled up or down automatically to meet usage patterns and optimize spending, or shut down temporarily or permanently.
The billing for AWS services becomes an operational expense rather than a capital expense.
Cloud adoption requires that fundamental changes are discussed and considered across the entire organization, and that stakeholders across all organizational units—both outside and within IT—support these changes.
The AWS Cloud Adoption Framework (AWS CAF) provides guidance that supports each unit in your organization so that each area understands how to update skills, adapt existing processes, and introduce new processes to take maximum advantage of the services provided by cloud computing.
Thousands of organizations around the world have successfully migrated their businesses to the cloud, relying on the AWS CAF to guide their efforts.
AWS and our partners provide tools and services that can help you every step of the way to ensure complete understanding and transition.
At the highest level, the AWS CAF organizes guidance into six focus areas.
We describe these focus areas as Perspectives.
Figure 1 shows the six Perspectives of the AWS CAF.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Search Amazon for other information about MuleSoft (paid link) https://amzn.to/3A8DV8uAs an Amazon Associate I earn from qualifying purchases. Thanks.
Introduction
Whether it’s building connected customer experiences or the ability to scale with changing market demands, the benefits of automation are unmistakable.
Yet many IT leaders struggle to enable automation across the enterprise — and do it in the right way.
As Central IT encounters repetitive or robotic tasks, they may recognize an opportunity for automation.
However, they often sacrifice strategic thinking in favor of shortcuts and point solutions that address only a few immediate priorities but are often unusable in other projects.
These seemingly small, inconsequential decisions can eventually become a mountain of technical debt and a decentralized patchwork of automation solutions.
Additionally, most organizations haven’t created a process by which business users can execute on automation opportunities.
Not enabling these teams ultimately undermines the company’s ability to quickly respond to shifting business conditions and changing customer expectations.
It is incumbent, therefore, on CIOs and other IT leaders to centrally enable their organizations so that the downstream outputs, like automation, inherit the important benefits of that central enablement: central management, central governance, and central security.
All of this is dependent on building a composable enterprise.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
This paper is a practical playbook for defining, establishing, and implementing a Cloud Enablement Engine (CEE).
It collates and summarizes the lessons learned and anti- patterns gathered from the CEE journeys successfully navigated at Amazon and other large enterprise companies.
Much has been written about the need to establish a CEE, the benefits of moving to a productization mindset, and the business value of tribes, guilds, and two-pizza teams.
However, larger organizations are still struggling with a CEE 30-60-90-day plan, and the essential components of the CEE during its first six months in existence.
The prescriptive guidance in this document provides pragmatic and tactical advice for establishing a Cloud Enablement Engine (CEE), also referred to as a Cloud Center of Excellence (CCoE) or Cloud Enablement Team.
This paper serves as a step-by-step guide for the initial setup activities, and the top ten best practices that have been extrapolated from working across a large number of customers.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Introduction
The multi-tier application (three-tier, n-tier, etc.)
has been a cornerstone architecture pattern for decades.
The multi-tier pattern provides good guidelines for you to follow to ensure decoupled and scalable application components that can be separately managed and maintained (often by distinct teams).
Multitiered applications are often built using a service-oriented architecture (SOA) approach to using web services.
In this approach, the network acts as the boundary between tiers.
However, there are many undifferentiated aspects of creating a new web service tier as part of your application.
Much of the code written within a multi-tier web application is a direct result of the pattern itself.
Examples include code that integrates one tier to another, code that defines an API and a data model that the tiers use to understand each other, and securityrelated code that ensures that the tiers’ integration points are not exposed in an undesired way.
Amazon API Gateway1, a service for creating and managing APIs, and AWS Lambda2, a service for running arbitrary code functions, can be used together to simplify the creation of robust multi-tier applications.
Amazon API Gateway’s integration with AWS Lambda enables user defined code functions to be triggered directly via a user-defined HTTPS request.
Regardless of the request volume required, both the API Gateway and Lambda will scale automatically to support exactly the needs of your application.
When combined, you can create a tier for your application that allows you to write the code that matters to your application and not focus on various other undifferentiating aspects of implementing a multi-tiered architecture—like architecting for high availability, writing client SDKs, server/operating system (OS) management, scaling, and implementing a client authorization mechanism.
More recently, AWS has announced the ability to create Lambda functions that execute within your Amazon Virtual Private Cloud (Amazon VPC).
This feature extends the benefits of combining API Gateway and Lambda to include a variety of use cases where network privacy is required.
For example, when you need to integrate your web service with a relational database that contains sensitive information.
The integration of Lambda and Amazon VPC has indirectly expanded the capabilities of Amazon API Gateway because it gives developers the
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Introduction
A core reason organizations adopt a cloud IT infrastructure is to save money.
The traditional approach of analyzing Total Cost of Ownership no longer applies when you move to the cloud.
Cloud services provide the opportunity for you to use only what you need and pay only for what you use.
We refer to this new paradigm as the Total Cost of Operation.
You can use Total Cost of Operation (TCO) analysis methodologies to compare the costs of owning a traditional data center with the costs of operating your environment using AWS Cloud services.
Eliminate Upfront Sunk Costs Organizations considering a transition to the cloud are often driven by their need to become more agile and innovative.
The traditional capital expenditure (CapEx) funding model makes it difficult to quickly test new ideas.
The AWS Cloud model gives you the agility to quickly spin up new instances on AWS, and the ability to try out new services without investing in large upfront, sunk costs (costs that have already been incurred and can’t be recovered).
If you are using the cloud you can return CapEx to the general fund and invest in activities that better serve your constituents.
AWS helps lower customer costs through its “pay only for what you use” pricing model.
To get started, it is critical to understand how to measure value, improve the economics of a migration project, manage migration costs and expectations through large-scale IT transformations, and optimize the cost of operation.
Launch an Amazon EC2 Instance for Free The AWS Free Tier lets you gain free, hands-on experience with AWS products and services.
AWS Free Tier includes 750 hours of Linux and Windows t2.micro instances each month for one year.
To stay within the Free Tier, use only EC2 Micro instances.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Five Stages to Streaming Platform Adoption
Recommendations for Business Executives
At Confluent, we’ve worked with a number of organizations that have architected themselves around event streaming platforms, to the extent the platform has become fundamental to how the business operates.
These organizations range from digital natives to more traditional companies across Financial Services, Retail, Automotive, Telecom, Healthcare and Government.
In fact, we’ve seen adoption in any industry in which data is critical, which of course is every industry.
Indeed, this year’s Apache Kafka® report found that 94% of organizations plan to deploy new applications or systems using Kafka as their event streaming platform.
And two-thirds [67%] plan to deploy between 1 and 10 new applications or systems.
Use cases for event streaming platforms vary from improving the customer experience, to facilitating new business models, to driving increased efficiency and/or mitigating risk.
Regardless of the use case, through working with many of these organizations, we have synthesized some common themes of streaming maturity and have identified five stages of adoption, as shown in Figure 1.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Overview.
We’re in an unprecedented time and going through the largest digital transformation in history, where enterprises are moving from using software to becoming software-driven.
This is a trend being manifested across all industries: financial services, retail, manufacturing, trans- portation and logistics, media and entertainment, healthcare, and many more.
To become a software-driven business that operates in real time, enterprises are undertaking multiple modernization initiatives, including application modernization, artificial intelligence and machine learning, the cloud, and edge analytics.
But modern applications no longer live in isolation.
They are built on microservices and rely on other services to move data between applica- tions.
Nowadays, modern distributed applications comprise hundreds of thousands of remote services operating in multiple tiers, all of which are loosely coupled and need to exchange data with each other.
In such distributed architectures, reliable data and message distribution is key.
Message-oriented middleware or messaging middleware has been widely used to handle the needs of message distribution and interservice communication across distributed applications.
Message-oriented middleware systems like enterprise service buses (ESBs), message queues (MQs), and data integration tooling for extract, transform, and load (ETL) act as the critical layer among services that need to communi- cate.
REST APIs have also emerged recently to enable simple point-to-point communication.
This paper takes a look at six Confluent customer implementations, the challenges posed by legacy approaches to messaging middleware, and the strategies they used to overcome them.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Build, share, and run any app, anywhere.
Loved by millions of developers.
Trusted by thousands of businesses.
With over 13M active developers and more than 13B image pulls per month - we’ve got you covered.
Docker is the #1 most wanted and #2 most loved developer tool, and helps millions of developers build, share and run any app, anywhere - on-prem or in the cloud.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Executive Summary.
Many organizations have enjoyed great success building and operating their websites and business-critical database-driven web applications on the popular open-source MySQL database.
While MySQL is a costeffective, flexible, and scalable platform that is preferred by many developers, the burden of deploying, managing, maintaining, securing, protecting, and tuning the database and associated components often falls upon the developers themselves.
For many organizations, managing a large number of on-premises MySQL instances has become complex and costly from an operational perspective.
Developers’ time is better spent developing applications and innovating new solutions rather than managing databases, resulting in improved developer productivity and faster application delivery, as well as improved product quality and capabilities.
ESG validated that, by migrating on-premises MySQL instances to the fully managed Azure Database for MySQL, organizations have reported significant operational savings, have reduced risk, and have improved the speed of application development and delivery.
ESG’s modeled scenario predicts that a medium-sized development organization with 26 developers and 200 MySQL instances could realize savings of up to 48% over a three-year period including an 86% lower cost of administration.
They could also realize improved revenue of $15.5M with earlier release of products, improved application uptime, and improved product quality by leveraging Azure Database for MySQL, resulting in a 92% return on investment (ROI).
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of
Rethinking the enterprise.
May 2021 keystone.ai.
By Alexandria Sheng, Ellen Wu, Ellora Sarkar, Amanda Pratt, Tom Kudrle, Ross Sullivan, Marco Iansiti.
Becoming an AI-first company: operationalizing objectives, benchmarks, and the transformation journey
Introduction.
We are living in extraordinary times.
Even before the pandemic, the global economy was undergoing dramatic change.
The deployment of digital networks, data platforms, and artificial intelligence has caused significant disruption and a growing divide between companies that have embraced digital transformation and those that have not.
To understand how to enable technology to drive maximum business impact, we need to think about the firm in a new way.
Our research shows that the core of the new, “AI First” enterprise is a different operating architecture – one centered on integrated data assets and designed to easily deploy AI and Data Analytics at scale, across any function or department, rapidly and efficiently.
This new architecture enables organizations to address a vast set of quickly changing business needs, spurring innovation well beyond IT and R&D and driving the agility necessary to not only survive but prosper in these challenging times.
The AI First organization is purpose-built to maximize the impact of technology, data, and artificial intelligence, and it is prepared to manage not only its opportunities, but also its challenges and risks.
Our research shows that being AI First is not the prerogative of “digital native” companies.
Even among traditional enterprises, many companies have invested in the kinds of organizational, architectural, and procedural transformation necessary for digital technology to flourish.
At the same time, digital native companies have much to learn, change, and improve.
Becoming an “AI First” organization is an ongoing journey.
This paper introduces the vision, trajectory, and assessment tools to guide organizations as they seek to make progress on this path.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Agility is on everyone’s lips—online searches for “agile transformation” yield around 100 million hits, and the stories of well-known pioneers circulate widely.
But is this just hype, or are there real benefits to be gained?
Is agility just noise from the IT department, or an opportunity that merits serious attention from the top team?
And if pursuing agility yields benefits, what is the recipe for success?
To find the answers, we conducted a McKinsey Global Survey that reached 2,190 respondents across industries and geographies.
We wanted to go beyond the fluff, so we asked respondents what, if anything, their companies did in practice to advance agility, and what hard numbers they achieved regarding business impact.
Their organizations fell into two broad groups: the first group consisted of organizations with no agile transformation efforts in process; the second group consisted of organizations on the move, pursuing, or having recently completed an agile transformation beyond a few individual teams (see sidebar “Organizations are on the move”).
Two-thirds of those pursuing a transformation, however, said that their organizations were just treading water, taking no decisive action, and consequently achieving little or no business impact.
Within this second group, we identified a select set of organizations (represented by 10 percent of the entire sample) that were driving highly successful agile transformations.
They were embracing agility at scale to create and capture value instead of treating agile as team-level experiments in discrete departments.
This means reimagining the entire organization as a network of high-performing teams, each going after clear, end-to-end businessoriented outcomes, and possessing all of the skills needed to deliver, such as a bank boosting the performance of customer journeys; a retailer analyzing turns and earns of product categories; a mining company reviewing productionand safety-process steps; an oil and gas company planning wells; a machinery player undertaking full product management, from R&D to go-to-market; or a teleoperator simplifying products.
The teams are essentially interconnected mini businesses, obsessed with creating value rather than just delivering functional tasks.
However, agility at scale goes beyond adding more agile teams and team-level practices.
The broader operating model, the connective tissue between and across the teams, also needs to be transformed.
The organizations driving highly successful agile transformations made sure to do that by building an effective, stable backbone.
This means optimizing the full operating model across strategy, structures, processes, people, and technology by going after flat and fluid structures built around high-performing cross-functional teams, instituting more frequent prioritization and resource-allocation processes, building a culture that enables psychological safety, and decoupling technology stacks.
Enterprise agility is thus a paradigm shift away from multilayered reporting structures, rigid annual budgeting, compliance-oriented culture, separation of business and technology, and other traits dominating organizations for the past hundred years.
If this is true, and not just hype, a discontinuity of this magnitude should provide an opportunity for organizations to turn their operating models into a competitive advantage—as did early adopters of lean in the 1990s.
While individual case studies and agile success stories have been plentiful, having quantifiable results and a larger sample allowed us to go beyond anecdotes for the first time.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Introduction
You know that security is important.
And whether your system is cloud native, has transitioned into the cloud with a traditional archi‐ tecture, or is just starting that journey, you know that the shift into the cloud has made security more complex than ever.
What’s more, security is now everyone’s job.
For decades, software development and delivery were slow pro‐ cesses.
Early enterprise software was delivered to customers by hand and installed by a trained technician.
Cloud providers have changed all that, leveraging economies of scale to offer capabilities that many organizations couldn’t achieve on their own and making it cheaper and easier to use virtualization technologies.
Fortunately, as more application hosting is outsourced to cloud pro‐ viders, the resulting changes have brought design, development, testing, deployment, and management teams closer together.
That’s important, because while virtualization offers fantastic opportunities and capabilities, it also means there are many more moving pieces than there used to be.
To handle that, not only do you need solid management capabilities—you also need automation.
In the cloud, automation is often referred to as orchestration, because there is one piece in the middle that has to keep all the ele‐ ments in tempo and on key.
Using a tool like Kubernetes to orches‐ trate the development, deployment, and runtime phases of containerized applications can help immensely with automating and scaling application delivery, but it’s not magic.
You’ll still need to bring together all of the groups involved in development, orchestra‐ tion, and deployment, because all of them will have different and important insights.
For example, when you introduce orchestration,
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Introduction
Over the past decade, organizations have increasingly embraced modern software development practices, public cloud infrastructure, and cloud-native software such as Kubernetes and containers to fuel their digital transformation and innovation.
At the center of these changes is DevOps, a set of practices and tools designed to enable teams to deliver software applications and manage infrastructure environments at high velocity.
DevOps emphasizes principles such as increased collaboration, shared responsibility for development and operations, removing barriers between operational teams, and autonomous decision-making, all in the spirit of achieving greater speed and consistency.
DevOps relies on methodologies that use automation and continuous integration and delivery (CI/CD), and treats infrastructure and application components as immutable.
These changes can strain existing security programs.
DevOps-driven adoption of new technologies and processes may mean security is an afterthought and can expose new gaps in security coverage and risk management.
Security teams must therefore work toward a familiar set of goals for modern computing environments—avoiding security incidents, breaches, and exposures; establishing security best practices and policies to be implemented on an organization-wide basis; and managing resources to minimize operational overhead, alert fatigue, tool sprawl, and manual investigative workflows—in ways that align with the approaches that engineering teams favor.
This has given rise to the concept of DevSecOps: the combination of DevOps practices and security strategies as a means for every organization to increase protection and reduce risk to their modern software environments.
This whitepaper provides an overview of what DevSecOps is and how organizations can adopt its practices in conjunction with technologies such as Kubernetes and containers to achieve strong, scalable security for their cloud-native environments.
Kubernetes security trends and challenges Organizations continue to rapidly shift their software development efforts to hybrid cloud environments focused on Kubernetes, containers, microservices, and service meshes.
These modernization efforts can substantially impact organizations by requiring new personnel skills, tooling, processes, and culture.
The introduction of new technical architectures and operational patterns associated with these efforts also results in security challenges that stem from greater complexity—for example, the number of cloud-native technologies that a single organization uses can easily climb into the dozens.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Executive summary
IT service tickets are also called “trouble” tickets, which seems fitting.
As enterprises of all types and sizes turn to their IT departments to advance their digital business capabilities, endless requests and alerts about infrastructure and software issues can demand and overwhelm IT teams’ time and attention.
With increasing complexity in their systems, enterprises face a greater likelihood of issues with connectivity, software compatibility, security disruptions, and data access glitches—all result- ing in service tickets.
Event-driven automation allows IT teams to deliver more responsive service because incidents can automatically be detected and remediated instead of being handled manually or relying on users to report issues via tickets.
The high cost of traditional IT service operations
IT administrators often receive a series of inquiries when users cannot log into their applications, fol- lowed by service tickets, thus creating workflows with multiple tickets for a single issue.
Even a simple router reboot or power outage at a remote site could result in multiple service tickets that take half or more of an administrator’s day to address.
Automating these workflows can free up staff to work on higher-priority service requests, which—ultimately—reduces costs.
Organizations can poten- tially spend hundreds of thousands a month handling IT service tickets manually.
Relying on manual intervention for IT service delivery may also result in lower end-user or customer satisfaction due to increased average first response times.
Among other expenses, the time agents and administrators spend actively addressing a service issue can be costly.
IT administrators—faced with tight budgets, overworked staff, and demanding business stakeholders—can struggle to deliver IT services that fulfill high expectations and demand.
IT teams need to close service tickets quickly, continuously improve service, and reduce the cost of IT opera- tions.
Adding self-learning intelligence and automation into the process can help them meet these challenges.
Inefficient IT service management often has direct financial and organizational conse- quences, including poor customer and end-user experiences, along with stress and overwork for IT staff and a lack of visibility into ongoing and likely persistent IT issues.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of
Platform operating model for the AI bank of the future.
by Brant Carson, Abhishek Chakravarty, Kristy Koh, and Renny Thomas
Don't forget to like and subscribe.
Thank you, Now let's go !
Technology alone cannot define a successful AI bank; the AI bank of the future also needs an operating model that brings together the right talent, culture, and organizational design.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of McKinsey Analytics,
Getting to know—and manage—your biggest AI risks.
A systematic approach to identifying and prioritizing AI risks can help organizations effectively target mitigation efforts.
by Kevin Buehler, Rachel Dooley, Liz Grennan, and Alex Singla.
Don't forget to like and subscribe.
Let's go !
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of
McKinsey Analytics, Rethinking AI talent strategy as automated machine learning comes of age.
by Holger Hürtgen, Sebastian Kerkhoff, Jan Lubatschowski, and Manuel Möller
Don't forget to like and subscribe.
Thank you, Now let's go !
McKinsey Analytics, Rethinking AI talent strategy as automated machine learning comes of age.
Do companies still need to hire a large contingent of data scientists to build machine learning models or can AutoML reduce the demand for this elusive talent?
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
The purpose of this document is to outline known considerations, design patterns, and solutions that customers can leverage today when considering hybrid dimensions of the AWS AI/ML stack across the entire machine learning (ML) lifecycle.
Due to the scalability, flexibility, and pricing models enabled by the cloud, we at AWS continue to believe that the majority of ML workloads are better suited to run in the cloud in the long haul.
However, given that less than 5% of overall IT spend is allocated for the cloud, the actual amount of IT spend on-premises is north of 95%.
This tells us that there is a sizeable underserved market.
Change is hard - particularly for enterprises.
The complexity, magnitude, and length of migrations can be a perceived barrier to getting started.
For these customers, we propose hybrid ML patterns as an intermediate step in their cloud and ML journey.
Hybrid ML patterns are those that involve a minimum of two compute environments, typically local compute resources such as personal laptops or corporate data centers, and the cloud.
See the Basics section for a full introduction to the concept of hybrid ML.
We think customers win when they deploy a workload that touches the cloud to get some value, and we at AWS are committed to supporting any customer’s success, even if only a few percentage points of that workload hit the cloud today.
This document is intended for individuals who already have a baseline understanding of machine learning, in addition to Amazon SageMaker.
We will not dive into best practices for Amazon SageMaker per se, nor into best practices for storage or edge services.
Instead, we will focus explicitly on hybrid workloads, and refer readers to resources elsewhere as necessary.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Amazon Web Services: Risk and Compliance
Abstract
AWS serves a variety of customers, including those in regulated industries.
Through our shared responsibility model, we enable customers to manage risk effectively and efficiently in the IT environment, and provide assurance of effective risk management through our compliance with established, widely recognized, frameworks, and programs.
This paper outlines the mechanisms that AWS has implemented to manage risk on the AWS side of the Shared Responsibility Model, and the tools that customers can leverage to gain assurance that these mechanisms are being implemented effectively.
Introduction
AWS and its customers share control over the IT environment.
Therefore, security is a shared responsibility.
When it comes to managing security and compliance in the AWS Cloud, each party has distinct responsibilities.
A customer’s responsibility depends on which services they are using.
However, in general, customers are responsible for building their IT environment in a manner that aligns with their specific security and compliance requirements.
This paper provides more details about each party’s security responsibilities and the ways customers can benefit from the AWS Risk and Compliance Program.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
BREAKING THE RANSOMWARE CYCLE.
U.S. NATIONAL POLICY OPTIONS.
by Christopher Ford and Charles Clancy.
Holding objects of value hostage until a ransom is paid for their release is an ancient vice, but it has acquired special salience in the digital age, as cyber criminals in this era of internet-facilitated computer network dependencies have learned to take data itself hostage in return for ransom payments.
The explosive growth of “ransomware” attacks in recent years is the result of dynamics in which the cost and risk to attackers have all but disappeared, victims’ incentives to pay promptly have increased, and the profitability of ransomware crime has duly exploded.
Predictably, this has attracted steadily more predators to the “game” of digital ransom, and has produced a “feeding frenzy” of ransomware attacks, which U.S. officials have labeled a national crisis.
We will be unable to rein in the ransomware problem unless we directly address the game-theoretical incentive structures that have produced this crisis.
By taking effective steps to realign these incentives—such as by incentivizing ransomware- resistant “best practices,” ending victims’ ability to pass cyber ransom costs along to insurance providers, imposing traditional “know your customer” and other associated banking regulatory practices upon cryptocurrency transactions, and taking steps to reduce cyber criminals’ ability to rely upon safe haven in jurisdictions such as Russia—we may be able to break the vicious circle in which we presently find ourselves.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Supercomputing performance in the cloud. Microsoft Azure and NVIDIA Bring Top 30 Supercomputer Performance to Public Cloud Services
00:00:00 Welcome
00:03:53 High-Performance Linpack (HPL)
00:05:33 The technology behind the Azure supercomputer-in-the-cloud service
00:06:45 Azure NDv4 VM instance details
00:09:10 Key takeaways
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of McKinsey Quarterly.
Three keys to faster, better decisions
Don't forget to like and subscribe.
Thank you, Now let's go !
Decision makers fed up with slow or subpar results take heart.
Three practices can help improve decision making and convince skeptical business leaders that there is life after death by committee.
by Aaron De Smet, Gregor Jost, and Leigh Weiss Two years ago, we wrote about how it was simultaneously the best and worst of times for decision makers in senior management.
Best because of more data, better analytics, and clearer understanding of how to mitigate the cognitive biases that often undermine corporate decision processes.
Worst because organizational dynamics and digital decision-making dysfunctions were causing growing levels of frustration among senior leaders we knew.
Since then, we’ve conducted research to more clearly understand this balance, and the results have been disquieting.
A survey we conducted recently with more than 1,200 managers across a range of global companies gave strong signs of growing levels of frustration with broken decision-making processes, with the slow pace
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of McKinsey's Quartly.
Return as a muscle.
How lessons from COVID-19 can shape a robust operating model for hybrid and beyond.
Don't forget to like and subscribe.
Thank you, Now let's go !
New research shows how resilient organizations thrived through the pandemic.
Here’s how to use those lessons to craft a better approach to how work gets done across time (real and asynchronous) and space (digital and physical).
by Aaron De Smet, Mihir Mysore, Angelika Reich, and Bob Sternfels In May 2020, we published an article arguing that the return to the workplace was a new muscle that organizations needed to develop, not a plan with a predictable timeline.
The need for organizations to build this muscle is especially urgent today, as vaccination levels around the world rise, infection and hospitalization levels in many countries decrease, and companies begin their return from remote.
Many companies are already in various stages of a physical return to the workplace.
In the United States, for example, employees are starting to return to office locations at a greater pace.
Consumer and retail footfall to headquarters has increased by 80 percent, travel and logistics are up 50 percent, and pharmaceutical and healthcare are up 10 percent.
A few short months ago, it wasn’t clear that business leaders would so fully embrace a return to the office.
But it’s now evident that they will.
Some 52 percent of C-suite executives we surveyed espouse an almost full return to the office, with workers on-site four days per week or more.
Nine out of ten think that employees will be in the office at least three days per week.
Company leaders have good reasons for wanting workers back in the office.
As the pandemic dragged on, people’s sense of belonging and social connections suffered, especially among newer employees.
Interactions across silos became increasingly difficult via remote.
Many women left the workforce, widening the gender gap.
Mental- health issues, grief, anxiety, and burnout are on the rise, reflecting a decline in the informal and intimate human connections that often occur at the workplace.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
It’s time for leaders to get real about hybrid.
Employers are ready to get back to significant in-person presence.
Employees aren’t.
The disconnect is deeper than most employers believe, and a spike in attrition and disengagement may be imminent.
by Aaron De Smet, Bonnie Dowling, Mihir Mysore, and Angelika Reich Once in a generation (if that), we have the opportunity to reimagine how we work.
In the 1800s, the Industrial Revolution moved many in Europe and the United States from fields to factories.
In the 1940s, World War II brought women into the workforce (if not the C-suite) at unprecedented rates.
In the 1990s, the explosion of PCs and email drove a rapid increase in productivity and the speed of decision making, ushering in the digital age as we know it today.
And in 2020, the COVID-19 pandemic drove employees out of offices to work from home.
Thanks to the development and wide distribution of COVID-19 vaccines, 2021 presents another such opportunity.
The return to the workplace is a chance to create a new, more effective operating model that works for companies and people navigating a world of increasing uncertainty.
There is, however, one big catch: employers must confront the broadening disconnect between how they and their employees see the future.
Employees don’t know what they want and are reevaluating their relationships with work More than three-quarters of C-suite executives recently surveyed by McKinsey report that they expected the typical “core” employee to be back in the office three or more days a week (Exhibit 1).
While they realize that the great work-from-home experiment was surprisingly effective, they also believe that it hurt organizational culture and belonging.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
This is a survey paper that explores six Cloud-based deployment archetypes for Cloud applications and the tradeoffs between them to achieve high availability, low end-user latency, and acceptable costs.
00:00:13 Abstract
00:01:29 1. Introduction
00:04:28 1.1 Principles of Availability
00:09:32 1.2 Types of Applications
00:11:03 1.3 Data Durability, Availability and Backup
00:14:02 1.4 Six Deployment Archetypes for Cloud Applications
00:18:02 2. Zonal
00:18:36 2.1 Single Zone
00:20:11 2.2 Primary Zone with Failover Zone
00:26:47 3. Regional
00:28:13 3.1 Single Region
00:32:56 3.2 Primary Region with Failover Region
00:37:21 4. Multi-Regional
00:40:38 4.2 DNS Load Balancing
00:45:30 4.3 DNS Load Balancing with Isolated Stacks
00:52:45 4.4 DNS LB with Custom Multi-Regional Load Balancing
00:54:22 5. Global
00:56:15 5.1 Global Anycast
00:58:36 5.2 Global Anycast LB with Isolated Regional Stacks
01:00:54 5.3 Global Services Stack
01:08:13 6. Hybrid
01:11:36 7. Multi-Cloud
01:19:21 8. Comparison
01:22:58 8.1 Failover-to-Standby vs. Load Balancing
01:25:54 8.2 Regional vs. Global Application Stacks
01:28:14 8.3 Instantaneous Recovery
01:29:30 8.4 Cost of Availability
01:32:34 9. Related Work
01:38:08 10. Summary
01:39:22 Acknowledgements
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Domain-‐Driven Design Reference Definitions and Pattern Summaries.
00:00:13 Acknowledgements
00:04:14 Definitions
00:05:04 Pattern Language Overview
00:05:06 I. Putting the Model to Work
00:06:08 Bounded Context
00:07:28 Ubiquitous Language
00:10:04 Continuous Integration
00:10:47 Model-‐Driven Design
00:12:10 Hands-‐on Modelers
00:13:31 Refactoring Toward Deeper Insight
00:14:26 II. Building Blocks of a
00:14:28 Model-‐Driven Design
00:14:56 Layered Architecture
00:16:56 Entities
00:18:15 Value Objects
00:19:27 Domain Events *
00:21:55 Services
00:22:42 Modules
00:24:10 Aggregates
00:25:43 Repositories
00:27:39 Factories
00:28:49 III. Supple Design
00:30:24 Intention-‐Revealing Interfaces
00:31:20 Side-‐Effect-‐Free Functions
00:32:22 Assertions
00:33:19 Standalone Classes
00:33:55 Closure of Operations
00:35:18 Declarative Design
00:37:18 Drawing on Established Formalisms
00:38:20 Conceptual Contours
00:40:02 IV. Context Mapping
00:40:04 for Strategic Design
00:41:27 Context Map
00:42:59 Partnership *
00:44:39 Shared Kernel
00:46:07 Customer/Supplier Development
00:47:25 Conformist
00:48:32 Anticorruption Layer
00:49:45 Open-‐host Service
00:51:02 Published Language
00:51:51 Separate Ways
00:52:17 Big Ball of Mud *
00:53:51 V. Distillation for Strategic Design
00:54:25 Core Domain
00:55:35 Generic Subdomains
00:56:33 Domain Vision Statement
00:57:22 Highlighted Core
00:59:41 Cohesive Mechanisms
01:00:48 Segregated Core
01:01:33 Abstract Core
01:02:20 VI. Large-‐scale Structure for
01:02:23 Strategic Design
01:03:17 Evolving Order
01:04:28 System Metaphor
01:05:30 Responsibility Layers
01:06:27 Knowledge Level
01:07:16 Pluggable Component Framework
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Executive Summary
DevOps is a mindset, a way of thinking, versus a set of processes implemented in a specific way.
The goal of all DevOps organiza- tions are the same: to improve the quality and speed at which in- novation is delivered.
What began an experiment has transformed into a movement to bring together software development and the operations to run the software closer together.
Over the years, industry leaders and DevOps practitioners have come together to identify patterns and best practices so that successful methods are shared to the next wave of DevOps practitioners.
Three principles known as “The Three Ways of DevOps” have been identified and these are principles that all other Devops pat- terns can be derived from.
The Three Ways of DevOps include: systems thinking, amplifying and shortening feedback loops and continuous learning.
These principles describe the values and philosophies that frame the processes, procedures, practices of DevOps, as well as the prescriptive steps.
The capabilities of the Docker platform with containerized compute, storage and networking for distributed applications provide promising results when applied to the Three Ways of DevOps principles.
From exponential speed to and ve- locity to streamlining the feedback loop and collaboration across teams.
Key takeaways from this paper include:
A deeper understanding of Three Ways of DevOps principles and their purpose
How to apply these principles with Docker into your organization
Examples of results and benefits from other practitioners’ experiences
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
Enterprise customers often request advice and learnings from Amazon Web Services (AWS) on how to accelerate the velocity of their cloud transformation.
This document describes an integrated approach to achieve speed and accelerate time to value while maintaining control and corporate guardrails.
This approach enables teams, delegates decision rights, promotes experimentation, and leverages a continuous improvement mindset.
The approach provides IT and business leaders with a mechanism to tailor and scale their value-driven cloud transformation programs.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
The pandemic brought work into the home for many and changed the nature of much in-person work as well.
What could it mean for the US economy if these patterns persist?
ONE OF THE hallmarks of the “age of COVID-19” has been a sharp rise in the number of people working remotely, along with the reorganization of how much in-person work is conducted.
Adapting to this reality has set into motion waves of follow-on impacts that flow through much of the US economy.
Even after we see a retreat from the current level of remote work, some of these changes will likely persist.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of McKinsey and Company.
Technology, Media and Telecommunications Practice's.
The next software disruption: How vendors must adapt to a new era.
Please like and subscribe.
Over the turbulent past decade, many legacy software players proved to be remarkably resilient.
Now they must adopt a new strategic playbook to weather the different challenges ahead.
by Paul Roche, Jeremy Schneider, and Tejas Shah
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of, Beyond business continuity, Google Whitepaper.
Three IT strategies for navigating change By Praveen Rajasekar
Executive Summary
Business continuity done right is more than just backup and disaster recovery.
Today, business continuity means running IT services without disruption, ensuring compliance, and staying agile to respond to the unexpected.
By standardizing infrastructure and skills, strengthening reliability, and simplifying operations you can fortify your business continuity plans, improve operational flexibility, and enable digital agility across your organization.
00:00:14 Executive Summary
00:00:44 Introduction
00:05:10 Standardize skills
00:07:20 Strengthen reliability
00:09:22 Simplify operations
00:12:40 Conclusion
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Executive Summary
Running your business in the cloud is good, but can running on multiple clouds be better?
Limiting yourself to a single cloud stack can come at a significant cost.
Instead of taking advantage of the unique capabilities of every cloud, you face the limitations of proprietary systems.
Rather than uncovering more insights with best-of-breed tools, siloed data and data gravity slow down your analysis.
Where there could be resilience that comes from entirely different systems, there is concentrated risk.
These are big tradeoffs to make in exchange for the simplicity of running on just one cloud.
To diversify their cloud strategy and avoid these limitations, many organizations (81% of enterprises surveyed by Gartner¹) have turned to multicloud and hybrid deployments.
If you’re thinking of going down this path, we want to partner with you on this journey.
Here are five reasons to partner with Google Cloud on your multicloud journey
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
Cloud procurement presents an opportunity to reevaluate existing procurement strategies so you can create a flexible acquisition process that enables your public sector organization to extract the full benefits of the cloud.
Cloud procurement considerations are key components that can form the basis of a broader public sector cloud procurement strategy.
This paper presents the top 10 cloud procurement considerations for the public sector.
00:00:14 Abstract
00:00:40 Introduction
00:01:21 Cloud procurement considerations
00:01:43 Understand why cloud computing is different
00:02:45 Plan early to extract the full benefit of the cloud
00:03:30 Avoid overly prescriptive requirements
00:05:00 Separate cloud infrastructure (unmanaged
00:05:03 services) from managed services
00:05:52 Incorporate a utility pricing model
00:07:25 Leverage third-party accreditations for security,
00:07:28 privacy, and auditing
00:09:17 Understand that security is a shared responsibility
00:10:04 Design and implement cloud data governance
00:11:06 Specify commercial item terms
00:11:54 Define cloud evaluation criteria
00:12:37 Conclusion
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Introduction
As more and more enterprises look at leveraging the capabilities of public clouds, they face an array of important decisions.
For example, they must decide which cloud(s) and what technologies they should use, how they operate and manage resources, and how they deploy applications.
A lot of technologies can help, but not all of them are equal.
If you have heavily invested time, money, and energy in creating software, shouldn’t you have the ability to deploy and manage that software seamlessly across your hybrid environments and avoid the costs of rewriting it?
How can you scale your software to meet customer demand?
Do you want to deploy your software where it makes sense, whether on-premises or to a specific public cloud, based on business value?
This white paper discusses how Kubernetes is the answer to your hybrid cloud strategy and how it provides a holistic solution that simplifies your deployment, management, and operational concerns.
The paper also provides links to additional resources that can help you refine your hybrid cloud strategy.
00:00:19 Introduction
00:01:22 Kubernetes: What is it?
00:01:54 Problems of the past
00:02:51 What a hybrid strategy offers
00:04:12 Kubernetes and Google
00:06:19 Bringing it all together
00:07:37 Conclusion
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Unpicking Vendor Lock-in.
A guide to understanding and mitigating switching costs when changing your Cloud Services Provider.
Introduction
Customers should be able to switch their Cloud Services Provider (CSP) if they wish.
A CSP, or vendor, should earn customer business by providing the best services and capabilities at the best price.
If a CSP makes it difficult to switch away from them (the essential element of vendor lock-in), it suggests that their services are not earning customer trust through the value they bring, and that they are restricting customer choice.
At Amazon Web Services (AWS), we provide customers with full control, ownership, and portability of their data, and allow customers to quickly move to another CSP should they choose to.
We never want to trap customers with lock-in tactics such as fixed-price, mandatory long-term contracts, or technical hurdles to changing CSP that amount to vendor lock-in.
We want customers to stay with us because we offer the broadest choice of the best cloud services.
Our outlook is that our customers are loyal to us right up until the moment that somebody else offers them a better service.
This drives our customer- obsessed approach to innovation, and ensures we earn customer trust on a continuous basis.
This whitepaper looks at what customers should require from CSPs so they have the freedom to choose the innovative services they need, coupled with the ability to turn things off and move — should they decide to do so.
It provides a practical approach to defining, understanding, and eliminating sources of vendor lock-in.
The commentary in this paper is based on AWS’s many years of experience in delivering a secure cloud infrastructure to millions of customers worldwide.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract This whitepaper provides guidance and options for running Docker on AWS. Docker is an open platform for developing, shipping, and running applications in a loosely isolated environment called a container. Amazon Web Services (AWS) is a natural complement to containers and offers a wide range of scalable infrastructure services upon which containers can be deployed. You will find various options such as AWS Elastic Beanstalk, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, and AWS App Runner. This paper cover details of each option and key components of the container orchestration.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
Data engineers, data analysts, and big data developers are looking to evolve their analytics from batch to real-time so their companies can learn about what their customers, applications, and products are doing right now and react promptly.
This whitepaper discusses the evolution of analytics from batch to real-time.
It describes how services such as Amazon Kinesis Streams, Amazon Kinesis Firehose, and Amazon Kinesis Analytics can be used to implement real- time applications, and provides common design patterns using these services.
Introduction
Businesses today receive data at massive scale and speed due to the explosive growth of data sources that continuously generate streams of data.
Whether it is log data from application servers, clickstream data from websites and mobile apps, or telemetry data from Internet of Things (IoT) devices, it all contains information that can help you learn about what your customers, applications, and products are doing right now.
Having the ability to process and analyze this data in real-time is essential to do things such as continuously monitor your applications to ensure high service uptime and personalize promotional offers and product recommendations.
Real-time processing can also make other common use cases, such as website analytics and machine learning, more accurate and actionable by making data available to these applications in seconds or minutes instead of hours or days.
Real-time Application Scenarios
There are two types of use case scenarios for streaming data applications:
Evolving from Batch to Streaming Analytics You can perform real-time analytics on data that has been traditionally analyzed using batch processing in data warehouses or using Hadoop frameworks.
The most common use cases in this category include data lakes, data science, and machine learning.
You can use streaming data solutions to continuously load real-time data into your data lakes.
You can also update machine learning models more frequently as new data becomes available, ensuring accuracy and reliability of the outputs.
For example, Zillow uses Amazon Kinesis Streams to collect public record data and MLS listings, and then provide home buyers and sellers with the most up-to-date home value estimates in near real-time.
Zillow also sends the same data to its Amazon Simple Storage Service (S3) data lake using Kinesis Streams so that all the applications work with the most recent information.
Building Real-Time Applications You can use streaming data services for real-time applications such as application monitoring, fraud detection, and live leaderboards.
These use cases require millisecond end-to-end latencies—from ingestion, to processing, all the way to emitting the results to target data stores and other systems.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Welcome to the AGPIAL audiobook production of
McKinsey Digital's.
How enterprise architects need to evolve to survive in a digital world.
Enterprise architects still have an important role to play at large incumbents, but they need to evolve in three ways.
by Oliver Bossert and Niels van der Wildt
If you like this type of content please like and subscribe.
Thank you.
Many CIOs at large incumbents have made a startling discovery about digital natives: those businesses often don’t have architects or at least anyone with the formal title of “enterprise architect.”
With CIOs increasingly moving their organizations to an agile DevOps operating model, that discovery has prompted much questioning about whether they still need architects, and if so, what they should be doing.
While incumbents can learn plenty from digital natives and adopt many of their practices, eliminating the architect role shouldn’t be one of them.
That’s because digital natives have the benefits of a highly skilled and experienced workforce operating in a start-up culture on a modern architecture with few legacy issues.
Development teams in most incumbent organizations, however, don’t enjoy those benefits.
They are used to workarounds such as creating direct point-to-point connections because, for decades, that’s been the only way to get things done.
The reality is that most organizations still need architects.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
About this Guide
For many customers, migrating to Amazon EMR raises many questions about assessment, planning, architectural choices, and how to meet the many requirements of moving analytics applications like Apache Spark and Apache Hadoop from on-premises data centers to a new AWS Cloud environment.
Many customers have concerns about the viability of distribution vendors or a purely open-source software approach, and they need practical advice about making a change.
This guide includes the overall steps of migration and provides best practices that we have accumulated to help customers with their migration journey.
Overview
Businesses worldwide are discovering the power of new big data processing and analytics frameworks like Apache Hadoop and Apache Spark, but they are also discovering some of the challenges of operating these technologies in on-premises data lake environments.
Not least, many customers need a safe long-term choice of platform as the big data industry is rapidly changing and some vendors are now struggling.
Common problems include a lack of agility, excessive costs, and administrative headaches, as IT organizations wrestle with the effort of provisioning resources, handling uneven workloads at large scale, and keeping up with the pace of rapidly changing, community-driven, open-source software innovation.
Many big data initiatives suffer from the delay and burden of evaluating, selecting, purchasing, receiving, deploying, integrating, provisioning, patching, maintaining, upgrading, and supporting the underlying hardware and software infrastructure.
A subtler, if equally critical, problem is the way companies’ data center deployments of Apache Hadoop and Apache Spark directly tie together the compute and storage resources in the same servers, creating an inflexible model where they must scale in lock step.
This means that almost any on-premises environment pays for high amounts of under-used disk capacity, processing power, or system memory, as each workload has different requirements for these components.
How can smart businesses find success with their big data initiatives?
Migrating big data (and machine learning) to the cloud offers many advantages.
Cloud infrastructure service providers, such as Amazon Web Services (AWS), offer a broad choice of on-demand and elastic compute resources, resilient and inexpensive persistent storage, and managed services that provide up-to-date, familiar environments to develop and operate big data applications.
Data engineers, developers, data scientists, and IT personnel can focus their efforts on preparing data and extracting valuable insights.
Services like Amazon EMR, AWS Glue, and Amazon S3 enable you to decouple and scale your compute and storage independently, while providing an integrated, well- managed, highly resilient environment, immediately reducing so many of the problems of on-premises approaches.
This approach leads to faster, more agile, easier to use, and more cost-efficient big data and data lake initiatives.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Building a Scalable and Secure Multi-VPC AWS Network Infrastructure AWS Whitepaper. AGPIAL Audiobook Abstract AWS customers often rely on hundreds of accounts and VPCs to segment their workloads and expand their footprint. This level of scale often creates challenges around resource sharing, inter-VPC connectivity, and on-premises to VPC connectivity. This whitepaper describes best practices for creating scalable and secure network architectures in a large network using AWS services like Amazon VPC, AWS Transit Gateway, AWS PrivateLink, and AWS Direct Connect Gateway. It demonstrates solutions for managing growing infrastructure — ensuring scalability, high availability, and security while keeping overhead costs low.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
AWS Security Incident Response Guide
This guide presents an overview of the fundamentals of responding to security incidents within a customer’s AWS Cloud environment.
It focuses on an overview of cloud security and incident response concepts, and identifies cloud capabilities, services, and mechanisms that are available to customers who are responding to security issues.
This paper is intended for those in technical roles and assumes that you are familiar with the general principles of information security, have a basic understanding of incident response in your current on- premises environments, and have some familiarity with cloud services.
Introduction
Security is the highest priority at AWS.
As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
The AWS Cloud has a shared responsibility model.
AWS manages security of the cloud.
You are responsible for security in the cloud.
This means that you retain control of the security you choose to implement.
You have access to hundreds of tools and services to help you meet your security objectives.
These capabilities help you establish a security baseline that meets your objectives for your applications running in the cloud.
When a deviation from your baseline does occur (such as by a misconfiguration), you may need to respond and investigate.
To successfully do so, you must understand the basic concepts of security incident response within your AWS environment, as well as the issues you need to consider to prepare, educate, and train your cloud teams before security issues occur.
It is important to know which controls and capabilities you can use, to review topical examples for resolving potential concerns, and to identify remediation methods that you can use to leverage automation and improve your response speed.
Because security incident response can be a complex topic, we encourage you to start small, develop runbooks, leverage basic capabilities, and create an initial library of incident response mechanisms to iterate from and improve upon.
This initial work should include your legal department as well as teams that are not involved with security, so that you are better able to understand the impact that incident response (IR), and the choices you have made, have on your corporate goals.
Before You Begin
In addition to this document, we encourage you to review the Best Practices for Security, Identity, & Compliance and the Security Perspective of the AWS Cloud Adoption Framework (CAF) whitepaper.
The AWS CAF provides guidance that supports coordinating between the different parts of organizations that are moving to the cloud.
The CAF guidance is divided into several areas of focus that are relevant to implementing cloud-based IT systems, which we refer to as perspectives.
The Security Perspective describes how to implement a security program across several workstreams, one of which focuses on incident response.
This document details some of our experiences in helping customers to assess and implement successful mechanisms in that workstream.
AWS CAF Security Perspective
The Security Perspective includes four components:
Directive controls establish the governance, risk, and compliance models within which the environment operates.
Preventive controls protect your workloads and mitigate threats and vulnerabilities.
Detective controls provide full visibility and transparency over the operation of your deployments in AWS.
Responsive controls drive remediation of potential deviations from your security baselines.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
AWS Key Management Service Best Practices AWS Key Management Service Best Practices
Abstract
AWS Key Management Service (AWS KMS) is a managed service that allows you to concentrate on the cryptographic needs of your applications while Amazon Web Services (AWS) manages availability, physical security, logical access control, and maintenance of the underlying infrastructure.
Further, AWS KMS allows you to audit usage of your keys by providing logs of all API calls made on them to help you meet compliance and regulatory requirements.
Customers want to know how to effectively implement AWS KMS in their environment.
This whitepaper discusses how to use AWS KMS for each capability described in the AWS Cloud Adoption Framework (CAF) Security Perspective whitepaper, including the differences between the different types of customer master keys, using AWS KMS key policies to ensure least privilege, auditing the use of the keys, and listing some use cases that work to protect sensitive information within AWS.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
AWS Security at Scale: Logging in AWS How AWS CloudTrail can help you achieve compliance by logging API calls and changes to resources. AGPIAL Audiobook Abstract The logging and monitoring of API calls are key components in security and operational best practices, as well as requirements for industry and regulatory compliance. AWS CloudTrail is a web service that records API calls to supported AWS services in your AWS account and delivers a log file to your Amazon Simple Storage Service (Amazon S3) bucket. AWS CloudTrail alleviates common challenges experienced in an on-premise environment and in addition to making it easier for you to demonstrate compliance with policies or regulatory standards, the service makes it easier for you to enhance your security and operational processes. This paper provides an overview of common compliance requirements related to logging and details how AWS CloudTrail features can help satisfy these requirements. There is no additional charge for AWS CloudTrail, aside from standard charges for S3 for log storage and SNS usage for optional notification.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
This whitepaper is intended for existing and potential customers who are designing the security infrastructure and configuration for applications running in Amazon Web Services (AWS). It provides security best practices that will help you define your Information Security Management System (ISMS) and build a set of security policies and processes for your organization so you can protect your data and assets in the AWS Cloud. The whitepaper also provides an overview of different security topics such as identifying, categorizing and protecting your assets on AWS, managing access to AWS resources using accounts, users and groups and suggesting ways you can secure your data, your operating systems and applications and overall infrastructure in the cloud. The paper is targeted at IT decision makers and security personnel and assumes that you are familiar with basic security concepts in the area of networking, operating systems, data encryption, and operational controls.
Overview
Information security is of paramount importance to Amazon Web Services (AWS) customers. Security is a core functional requirement that protects mission- critical information from accidental or deliberate theft, leakage, integrity compromise, and deletion. Under the AWS shared responsibility model, AWS provides a global secure infrastructure and foundation compute, storage, networking and database services, as well as higher level services. AWS provides a range of security services and features that AWS customers can use to secure their assets. AWS customers are responsible for protecting the confidentiality, integrity, and availability of their data in the cloud, and for meeting specific business requirements for information protection.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
The focus of this paper is the security pillar of the AWS Well-Architected Framework.
It provides guidance to help you apply best practices, current recommendations in the design, delivery, and maintenance of secure AWS workloads.
ntroduction
The AWS Well-Architected Framework helps you understand trade-offs for decisions you make while building workloads on AWS.
By using the Framework, you will learn current architectural best practices for designing and operating reliable, secure, efficient, and cost-effective workloads in the cloud.
It provides a way for you to consistently measure your workload against best practices and identify areas for improvement.
We believe that having well-architected workloads greatly increases the likelihood of business success.
The framework is based on five pillars:
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization This paper focuses on the security pillar.
This will help you meet your business and regulatory requirements by following current AWS recommendations.
It’s intended for those in technology roles, such as chief technology officers (CTOs), chief information security officers (CSOs/CISOs), architects, developers, and operations team members.
After reading this paper, you will understand AWS current recommendations and strategies to use when designing cloud architectures with security in mind.
This paper doesn’t provide implementation details or architectural patterns but does include references to appropriate resources for this information.
By adopting the practices in this paper, you can build architectures that protect your data and systems, control access, and respond automatically to security events.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• Amazon Aurora (p. 23)
• Amazon Relational Database Service (p. 23)
• Amazon RDS on VMware (p. 23)
• Amazon DynamoDB (p. 23)
• Amazon ElastiCache (p. 24)
• Amazon Neptune (p. 24)
• Amazon Quantum Ledger Database (QLDB) (p. 24)
• Amazon Timestream (p. 25)
• Amazon DocumentDB (with MongoDB compatibility) (p. 25)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• Amazon Connect (p. 22)
• Amazon SES (p. 22)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• Amazon EC2 (p. 18)
• Amazon EC2 Auto Scaling (p. 19)
• Amazon Elastic Container Registry (p. 19)
• Amazon Elastic Container Service (p. 19)
• Amazon Elastic Kubernetes Service (p. 19)
• Amazon Lightsail (p. 20)
• AWS Batch (p. 20)
• AWS Elastic Beanstalk (p. 20)
• AWS Fargate (p. 20)
• AWS Lambda (p. 21)
• AWS Serverless Application Repository (p. 21)
• AWS Outposts (p. 21)
• VMware Cloud on AWS (p. 21)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• Alexa for Business (p. 17)
• Amazon WorkDocs (p. 17)
• Amazon WorkMail (p. 17)
• Amazon Chime (p. 18)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• Amazon Managed Blockchain (p. 16)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• AWS Cost Explorer (p. 15)
• AWS Budgets (p. 16)
• AWS Cost & Usage Report (p. 16)
• Reserved Instance (RI) Reporting (p. 16)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics • Amazon Sumerian (p. 15)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• AWS Step Functions (p. 14)
• Amazon MQ (p. 14)
• Amazon SQS (p. 14)
• Amazon SNS (p. 15)
• Amazon SWF (p. 15)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Topics
• Amazon Athena (p. 10)
• Amazon EMR (p. 10)
• Amazon CloudSearch (p. 11)
• Amazon Elasticsearch Service (p. 11)
• Amazon Kinesis (p. 11)
• Amazon Kinesis Data Firehose (p. 11)
• Amazon Kinesis Data Analytics (p. 12)
• Amazon Kinesis Data Streams (p. 12)
• Amazon Kinesis Video Streams (p. 12)
• Amazon Redshift (p. 12)
• Amazon QuickSight (p. 12)
• AWS Data Pipeline (p. 12)
• AWS Glue (p. 13)
• AWS Lake Formation (p. 13)
• Amazon Managed Streaming for Apache Kafka (Amazon MSK) (p. 13)
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Amazon Web Services Cloud Platform
AWS Management Console
Access and manage Amazon Web Services through the AWS Management Console, a simple and intuitive user interface.
You can also use the AWS Console Mobile Application to quickly view resources on the go.
AWS Command Line Interface
The AWS Command Line Interface (CLI) is a unified tool to manage your AWS services.
With just one tool to download and configure, you can control multiple AWS services from the command line and automate them through scripts. Software Development Kits
Our Software Development Kits (SDKs) simplify using AWS services in your applications with an Application Program Interface (API) tailored to your programming language or platform.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
Amazon Web Services offers a broad set of global cloud-based products including compute, storage, databases, analytics, networking, mobile, developer tools, management tools, IoT, security, and enterprise applications: on-demand, available in seconds, with pay-as-you-go pricing.
From data warehousing to deployment tools, directories to content delivery, over 175 AWS services are available.
New services can be provisioned quickly, without the upfront capital expense.
This allows enterprises, start-ups, small and medium-sized businesses, and customers in the public sector to access the building blocks they need to respond quickly to changing business requirements.
This whitepaper provides you with an overview of the benefits of the AWS Cloud and introduces you to the services that make up the platform.
Introduction
In 2006, Amazon Web Services (AWS) began offering IT infrastructure services to businesses as web services—now commonly known as cloud computing.
One of the key benefits of cloud computing is the opportunity to replace upfront capital infrastructure expenses with low variable costs that scale with your business.
With the cloud, businesses no longer need to plan for and procure servers and other IT infrastructure weeks or months in advance.
Instead, they can instantly spin up hundreds or thousands of servers in minutes and deliver results faster.
Today, AWS provides a highly reliable, scalable, low-cost infrastructure platform in the cloud that powers hundreds of thousands of businesses in 190 countries around the world.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
Since its introduction at AWS re:Invent in 2014, AWS Lambda has continued to be one of the fastest growing AWS services.
With its arrival, a new application architecture paradigm was created—referred to as serverless.
AWS now provides a number of different services that allow you to build full application stacks without the need to manage any servers.
Use cases like web or mobile backends, real-time data processing, chatbots and virtual assistants, Internet of Things (IoT) backends, and more can all be fully serverless.
For the logic layer of a serverless application, you can execute your business logic using AWS Lambda.
Developers and organizations are finding that AWS Lambda is enabling much faster development speed and experimentation than is possible when deploying applications in a traditional server-based environment.
This whitepaper is meant to provide you with a broad overview of AWS Lambda, its features, and a slew of recommendations and best practices for building your own serverless applications on AWS.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
This whitepaper outlines high-availability architectural best practices for customers who are considering integration between Amazon Virtual Private Cloud (Amazon VPC) in one or more regions with their existing Multiprotocol Label Switching (MPLS) network.
The whitepaper provides best practices for connecting single and/or multiregional configurations with your MPLS provider.
It also describes how customers can incorporate VPN backup for each of their remote offices to maintain connectivity to AWS Regions in the event of a network or MPLS outage.
The target audience of this whitepaper includes technology decision makers, network architects, and network engineers.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Abstract
This paper explains the features and benefits of using continuous integration, continuous delivery (CI/CD), and Amazon Web Services (AWS) tooling in your software development environment.
Continuous integration and continuous delivery are best practices and a vital part of a DevOps initiative.
Whitepaper available here.
https://d1.awsstatic.com/whitepapers/microservices-on-aws.pdf
00:00:06 Abstract
00:00:28 The Challenge of Software Delivery
00:03:13 What is Continuous Integration and
00:03:15 Continuous Delivery/Deployment?
00:03:28 Continuous Integration
00:04:51 Continuous Delivery and Deployment
00:05:48 Continuous Delivery Is Not Continuous Deployment
00:06:51 Benefits of Continuous Delivery
00:07:07 Automate the Software Release Process
00:07:22 Improve Developer Productivity
00:07:46 Improve Code Quality
00:08:25 Deliver Updates Faster
00:09:04 Implementing Continuous Integration and
00:09:06 Continuous Delivery
00:09:37 A Pathway to Continuous Integration/Continuous
00:09:40 Delivery
00:14:22 Maturity and Beyond
00:15:21 Teams
00:15:59 Application Team
00:16:33 Infrastructure Team
00:17:20 Tools Team
00:18:32 Testing Stages in Continuous Integration and
00:18:35 Continuous Delivery
00:20:20 Setting Up and Executing Builds
00:21:47 Staging
00:24:05 Building the Pipeline
00:28:28 Continuous Delivery Pipeline
00:29:58 Adding Lambda Actions
00:31:03 Manual Approvals
00:31:35 Deploying Infrastructure Code Changes in a CI/CD Pipeline
00:32:27 CI/CD for Serverless Applications
00:33:14 Pipelines for Multiple Teams, Branches, and Regions
00:33:58 Pipeline Integration with AWS CodeBuild
00:34:51 Pipeline Integration with Jenkins
00:36:23 Deployment Methods
00:36:53 All at Once (In-Place Deployment)
00:37:36 Rolling Deployment
00:38:49 Immutable and Blue/Green Deployment
00:39:51 Database Schema Changes
00:41:24 Summary of Best Practices
00:43:28 Conclusion
00:44:14 Further Reading
00:44:35 Contributors
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Designing Event-Driven Systems Concepts and Patterns for Streaming Services with Apache Kafka Ben Stopford Foreword by Sam Newman
https://assets.confluent.io/m/7a91acf41502a75e/original/20180328-EB-Confluent_Designing_Event_Driven_Systems.pdf
While the main focus of this book is the building of event-driven systems of dif‐ ferent sizes, there is a deeper focus on software that spans many teams.
This is the realm of service-oriented architectures: an idea that arose around the start of the century, where a company reconfigures itself around shared services that do commonly useful things.
This idea became quite popular.
Amazon famously banned all intersystem com‐ munications by anything that wasn’t a service interface.
Later, upstart Netflix went all in on microservices, and many other web-based startups followed suit.
Enterprise companies did similar things, but often using messaging systems, which have a subtly different dynamic.
Much was learned during this time, and there was significant progress made, but it wasn’t straightforward.
One lesson learned, which was pretty ubiquitous at the time, was that service- based approaches significantly increased the probability of you getting paged at 3 a.m., when one or more services go down.
In hindsight, this shouldn’t have been surprising.
If you take a set of largely independent applications and turn them into a web of highly connected ones, it doesn’t take too much effort to imagine that one important but flaky service can have far-reaching implications, and in the worst case bring the whole system to a halt.
As Steve Yegge put it in his famous Amazon/Google post, “Organizing into services taught teams not to trust each other in most of the same ways they’re not supposed to trust external devel‐ opers.” What did work well for Amazon, though, was the element of organizational change that came from being wholeheartedly service based.
Service teams think of their software as being a cog in a far larger machine.
As Ian Robinson put it, “Be of the web, not behind the web.” This was a huge shift from the way people built applications previously, where intersystem communication was something teams reluctantly bolted on as an afterthought.
But the services model made
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support
Managing Machine Learning Projects Balance Potential with the Need for Guardrails
The pdf version is available here. https://d1.awsstatic.com/whitepapers/aws-managing-ml-projects.pdf
This is a AGPIAL audiobook produced by Amazon Polly Text to Speech.
This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
Support this podcast: https://anchor.fm/agpial/support