The document discusses the challenges faced by two individuals, Sam and Stephanie, in their respective attempts to transition into roles as cloud architects, highlighting the importance of understanding cloud architecture fundamentals. It emphasizes that certifications alone are insufficient and that a holistic view of system design, as well as a comprehension of non-functional requirements (NFRs), are crucial for success. Additionally, it offers insights into cloud-native architecture principles and practical advice for developing skills relevant to cloud architecture.

1. AGILE ARCHITECTURE
IN A MODERN
CLOUD-NATIVE ECOSYSTEM
By Turja N Chaudhuri

4. Meet Sam .
Sam has around 10 years
of experience in IT as a
SysAdmin + IT Operator.
Sam recently completed 3
cloud certification exams.

5. With his newfound cloud
knowledge , Sam attends a
Cloud architecture
interview for a prestigious
IT firm .

6. Unfortunately , the interview
does not go well . He is asked
about topics he had not
encountered in the cloud
certification exams .
He gets rejected .

7. Meet Stephanie .
She works as a Lead
Developer in an IT
company.
She has developed quite a
few products using cloud
services.

8. She is asked to take over
the role of a Cloud
Architect for a large-scale
application which will be
published across the
enterprise.

9. She delivers the product , but it
is neither scalable ,nor resilient
enough , even though she is a
great coder , and had put the
best programming standards in
place .
She loses the trust of the client
and as a consequence , her
manager.

11. So , the million $ question is –
1 . What went wrong ?
2 . What did they (particularly) do wrong
?
3 . How can I/you prevent myself/ourself
from doing the same mistakes?

12. Hopefully , at the end of the talk ,
you(the audience) should be in a
better position to
answer these questions yourself !!
We will revisit these 2 scenarios at the end of this talk!!

14. Let me (briefly) introduce myself -

15. Currently , an Assistant Director,
Cloud Practice at EY (Ernst & Young).
Before that I led the CCOE ( Cloud
Centre Of Excellence Team ) at Accenture.
Have 10+ years of IT experience , working on
Cloud since 2017.
But , most importantly , I successfully transitioned
my career
from being a C#,SQL developer
to a Cloud solution architect.

16. I want to help you do the same , in case
you guys are interested

17. I will try to leave 5-10 minutes at the
end to address any queries you might
have on this topic.
So , you can ask the questions on chat .
If I cannot answer them during the session
I promise , I will personally reach out to you ,
and answer them later.

19. Agenda -

20. Before ,we go into Cloud Native
Architecture , we need to first understand
the basics.
Note –
Getting the basics right is very important.
In this ever-changing landscape of myriad technologies , it
is only possible to stay relevant , if you understand the
foundation topics .
The trick to note here is that the fundamentals / basics
have not changed that much over the years.
They have stood the test of time .
Today there is Kubernetes tomorrow there will be
something else , but the essence will stay the same (
mostly ).

21. Otherwise , the same issues we faced
earlier (in our on-prem systems
, for example ) , will potentially resurface.

22. What is architecture ?

23. IEEE 1471:2000 definition -
‘’The fundamental organization of a system embodied
in its components, their relationships to each other,
and to the environment, and the principles guiding
its design and evolution.’’

25. Grady Booch , IBM Fellow
‘’All architecture is design but not
all design is architecture;
architecture represents the set of
significant design decisions that shape
the structure and behaviour
of a system where significance
is measured by cost of change.’’
Ref - https://twitter.com/grady_booch/status/1257355498598342656?lang=en

26. Martin Fowler
https://www.youtube.com/watch?v=DngAZyWMGR0
“the set of design decisions
that must be made early”
What is architecture ?

27. Matthew Parker , previously Global Head
of engineering – Pivotal Labs
“Architecture , in the field of
software development ,
are decisions that are hard to reverse ”

28. Some examples could be -
“Whether to deploy our application on container based
compute environment like Kubernetes or go with
a serverless model like AWS Lambda ”
“Whether to go with synchronous API-based
communication or use a event-bus based asynchronous
messaging system like RabbitMQ/AWS SQS”
OR
OR
“What programming language do you use for your
application development”

30. Ok , then who/what are architects ?

32. “Architects have a holistic understanding
of the system , across a different spectrum
of views and viewpoints , and they offer a
different perspective of the
system/design.”

33. “The architect doesn’t have
to be the smartest
person in the room.
Instead they make
everyone else smarter.”
Gregor Hohpe ,
Enterprise Strategist , AWS
https://architectelevator.com/architecture/multiple-dimensions/

34. Why do we need architecture ?

36. Architecture matters -
“Bad architecture / no architecture slows down the ability of our customers to compete , as over time it becomes
harder and harder to ship new features”

37. https://martinfowler.com/bliki/DesignStaminaHypothesis.html
Let me explain ,

38. Ref - https://betterprogramming.pub/agile-
architecture-intent-vs-the-immediate-36d327289b2d
Agile architecture - Immediate Architecture to
Architecture Intent

39. But , what does this have to
do with me ?
Why do I care about
software/cloud architecture ?
Why would I want to become a Cloud
Architect?

40. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
“Almost all organizations are using at least one cloud”
Reason 1 – Cloud adoption is increasing

41. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
Reason 2 – Companies are spending
money on cloud

42. Reason 3 - Because , a 2020 survey by
the Job
search engine Indeed says – “Software
Architect is the best job ”
Look around you , you will see
that architects are typically
paid 5-10x , the salary
of standalone engineers/developers.

44. What is cloud architecture ?

46. Cloud architecture is the way technology components combine to build a cloud,
in which resources are pooled through
virtualization technology and shared across a network.
The components of a cloud architecture include:
• A front-end platform (the client or device used to access the cloud)
• A back-end platform (servers and storage)
• A cloud-based delivery model
• A network

48. If I had to define Cloud Architecture , or focus on a part of it , that makes the most sense to me , is to go with
the below analogy -
Pets Vs Cattle – If you understand this
you understand Cloud architecture

49. Scalability Reliability Efficient Secure
Maintainable Extensible Observable
Testable
So , in essence we can think of a cloud architecture
as an architecture / design that -

50. Noticed something ?
Essentially , nothing has changed .
All the constraints / quality
attributes that you
needed to maintain in your datacenter
based applications are relevant even now ,
more so than ever .

51. The cloud might
be new , but the
essence of
architecture
remains the
same .

52. Scalability Reliability Efficient Secure
Maintainable Extensible Observable
Testable
And if you can ensure that you manage your solution/architecture to align with the
below constraints/requirements , then you are already doing the right thing -

53. Essentially , the attributes that public cloud offer , for
example – infinite compute , pay as you go offering and so
on , helps architects in building solutions that respect the
quality attributes we discussed before .
Cloud Platforms / Cloud Service
Providers (AWS, Azure,GCP) help
architects in building better solutions

54. And these are
called – Non
Functional
Requirements

55. Normally , in architecture design , there
are different types of requirements
• Functional
• UI
• Business/Domain
• Non-Functional (NFR)

56. Being a cloud architect , you should
focus on documenting , defining ,
implementing and managing the NFR(s)
of the system you are designing.
Typically , these are documented in SADs (
Solution Architecture Documents )

58. Cloud-native architectures

59. Cornelia Davis , Amazon , Cloud
Foundry
“CLOUD-NATIVE = LOOSELY COUPLED
RUNNING IN THE CLOUD”
“Cloud is where you compute ,
Cloud-native is how you compute”
Ref - https://www.youtube.com/watch?v=VpZHLtu8mj0&t=1045s

60. Cloud native is a big topic , stretching across a lot
of components -

61. Principles of Cloud-native architectures
https://www.ibm.com/cloud/architecture/architecture/practices/cloud-native-principles/

62. Wait , what ?

63. “At a high-level , if you really think about it ,
Cloud native architecture principles
are just extensions of the best practices/standards
that enforces the same NFR(s)
that we discussed”

64. Let’s take an example –
One of the key principles of cloud native architectures
is immutability .
This means that the infrastructure is not modified in
place after deployment .
This means that we must have an automated way of
creating
a new instance of an application .
This means that if our existing application is down , we can
quickly create a new instance.
This means my application is (as a consequence) RELIABLE

65. So , simply put cloud-native application
architectures are a way to build better applications
that work better , scale better , are more reliable ,
take advantage of the cloud , provided
you play by the rules .

66. The last part is very important – you need to play by the
rules .
Cloud service providers like AWS ,Azure OR cloud native
platforms like Kubernetes , VMWare Tanzu are here
to help , but you still need to architect your
system correctly.
And that is where cloud architects come into play.

67. Cloud-native is an approach to
build & run applications that can
leverage the advantages of the
cloud computing model.
These applications are built and
deployed in a rapid cadence to
the cloud platform and offer
organizations greater agility,
resilience, and portability across
clouds.
In a nutshell ,

68. At this point , it makes sense to briefly introduce
some of the
tools , and practices that make designing
Cloud native applications possible -

69. Mostly , we start our cloud-native journey
by learning about docker , which is good .
But , please understand
Docker != Cloud native

70. But , it’s true , you should learn about
containers , as they really help in building
cloud-native applications .

71. Containers
Ref - https://www.docker.com/resources/what-container
A container is a standard unit of software that
packages up code and all its dependencies so
the application runs quickly and reliably from
one computing environment to another. A
Docker container image is a lightweight,
standalone, executable package of software
that includes everything needed to run an
application: code, runtime, system tools,
system libraries and settings.
Containers isolate software from its
its environment and ensure that it works
works uniformly despite differences for
differences for instance between development
development and staging.

72. It essentially solves -

73. But , then how do we manage multiple
containers ?
Container orchestration automates the deployment,
management, scaling, and networking of containers.
Enterprises that need to deploy and manage hundreds or
thousands of containers and hosts can benefit from
container orchestration.

74. Along came Kubernetes

75. Kubernetes -
Kubernetes is a portable, extensible, open-source
platform for managing containerized workloads and
services, that facilitates both declarative configuration
and automation.
It has a large, rapidly growing ecosystem. Kubernetes
services, support, and tools are widely available.

76. Microservices -
Microservice architectural style is an approach to
developing a single application as a suite of small services,
each running in its own process and communicating with
lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and
independently deployable by fully automated deployment
machinery.
There is a bare minimum of centralized management of
these services, which may be written in different
programming languages and use different data storage
technologies.

80. Cloud-study loop

81. Here , I want to share
a few small things that worked
for me in my journey to become
a better cloud architect .

82. Focus on developing T shaped skills -

83. 1 . Follow other ,
better solution
architects.

84. 2 . Listen to cloud
podcasts while
talking a walk , or
chilling out.

85. 3 . Write a small
program , in
whatever language ,
at least once a
month.

86. 4 . Subscribe to good
newsletters to stay
updated.

87. 5 . Get the basics
right .
Start with the why ,
before the how .

88. 6 . At work , try to get
a gig that lets you
think about
architecture.

89. 7 . Write at least one
blog , a month , on
technology , and
architecture , no
matter what.

90. 8 . Get certified , as
much as possible.

91. 9 . Try to speak on
cloud
technologies/software
architecture at events.

92. 10 . Attend as many
cloud interviews as
possible

93. There is no shortcut
to becoming a good
cloud architect.
You need to spend
the required time ,
and effort .

94. So , coming back to the question –
1 . What went wrong ?
2 . What did they do wrong ?
3 . How can I/you prevent
myself/ourself from doing the same
mistakes?

95. Scenario 1 ( Sam ) – Needs to understand
how architecture is important , and how
to design applications that respect the
NFR(s) to get a Cloud architect role ; only
certifications are not enough

96. Scenario 2 ( Stephanie ) – Only
programming/having a limited
perspective of a system will not help in
large-scale enterprise architecture.
Having a holistic view is equally
important , if not more.

98. Scan below QR code to contact me on LinkedIn

99. Or if you are URL kind-of-a-guy , use the below hyperlink -
TurjaChaudhuri-LinkedIn

101. Scalability
Ability to easily adapt to larger demand
by allowing greater supply.

102. Reliability
Ability to easily withstand interruptions
or failures.

103. Efficiency
Ability of the system
to easily perform at the required level.

104. Security
Ability to easily protect important
or trusted data from non-approved
entities.

105. Maintainability
Ability to easily manage and operate
a system over time.

106. Extensibility
Ability to easily add new features
to a system , by extending
existing modules.

107. Testability
Ability to easily test
a system for issues or bugs.

108. Observability
Ability to easily monitor a system
for changes / alerts.