Architecting Cloud Native Net Apps For Azure
V103 V103 Robert Vettor download
https://ebookbell.com/product/architecting-cloud-native-net-apps-
for-azure-v103-v103-robert-vettor-54231780
Explore and download more ebooks at ebookbell.com
Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Architecting Cloud Native Net Apps For Azure V102 Robert Vettor Steve
Ardalis Smith
https://ebookbell.com/product/architecting-cloud-native-net-apps-for-
azure-v102-robert-vettor-steve-ardalis-smith-34627612
Architecting Cloudnative Serverless Solutions Design Build And Operate
Serverless Solutions On Cloud And Open Source Platforms Safeer Cm
https://ebookbell.com/product/architecting-cloudnative-serverless-
solutions-design-build-and-operate-serverless-solutions-on-cloud-and-
open-source-platforms-safeer-cm-50501596
Architecting Cloud Native Applications Kamal Arora Erik Farr
https://ebookbell.com/product/architecting-cloud-native-applications-
kamal-arora-erik-farr-27028914
Architecting Cloud Native Applications Design Highperforming And
Costeffective Applications For The Cloud Kamal Arora
https://ebookbell.com/product/architecting-cloud-native-applications-
design-highperforming-and-costeffective-applications-for-the-cloud-
kamal-arora-47032738
Architecting Cloudnative Serverless Solutions Design Build And Operate
Serverless Solutions On Cloud And Open Source Platforms Cm
https://ebookbell.com/product/architecting-cloudnative-serverless-
solutions-design-build-and-operate-serverless-solutions-on-cloud-and-
open-source-platforms-cm-56267610
Managing Cloud Native Data On Kubernetes Architecting Cloud Native
Data Services Using Open Source Technology 1st Edition Jeff Carpenter
https://ebookbell.com/product/managing-cloud-native-data-on-
kubernetes-architecting-cloud-native-data-services-using-open-source-
technology-1st-edition-jeff-carpenter-53833350
Managing Cloud Native Data On Kubernetes Architecting Cloud Native
Data Services Using Open Source Technology Jeff Carpenter
https://ebookbell.com/product/managing-cloud-native-data-on-
kubernetes-architecting-cloud-native-data-services-using-open-source-
technology-jeff-carpenter-56280926
Managing Cloud Native Data On Kubernetes Architecting Cloud Native
Data Services Using Open Source Technology 1st Edition Jeff Carpenter
https://ebookbell.com/product/managing-cloud-native-data-on-
kubernetes-architecting-cloud-native-data-services-using-open-source-
technology-1st-edition-jeff-carpenter-56280924
Architecting Cloud Computing Solutions Build Cloud Strategies That
Align Technology And Economics While Effectively Managing Risk 1st
Edition Kevin L Jackson
https://ebookbell.com/product/architecting-cloud-computing-solutions-
build-cloud-strategies-that-align-technology-and-economics-while-
effectively-managing-risk-1st-edition-kevin-l-jackson-47173342
Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor
Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor
EDITION v1.0.3
Refer changelog for the book updates and community contributions.
PUBLISHED BY
Microsoft Developer Division, .NET, and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2023 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any
form or by any means without the written permission of the publisher.
This book is provided “as-is” and expresses the author’s views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change
without notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association
or connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the “Trademarks” webpage are
trademarks of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
Authors:
Rob Vettor, Principal MTC (Microsoft Technology Center) Architect for Cloud App Innovation -
thinkingincloudnative.com, Microsoft
Steve “ardalis” Smith, Software Architect and Trainer - Ardalis.com
Participants and Reviewers:
Cesar De la Torre, Principal Program Manager, .NET team, Microsoft
Nish Anil, Senior Program Manager, .NET team, Microsoft
Jeremy Likness, Senior Program Manager, .NET team, Microsoft
Cecil Phillip, Senior Cloud Advocate, Microsoft
Sumit Ghosh, Principal Consultant at Neudesic
Editors:
Maira Wenzel, Program Manager, .NET team, Microsoft
David Pine, Senior Content Developer, .NET docs, Microsoft
Version
This guide has been written to cover .NET 7 version along with many additional updates related to
the same “wave” of technologies (that is, Azure and additional third-party technologies) coinciding in
time with the .NET 7 release.
Who should use this guide
The audience for this guide is mainly developers, development leads, and architects who are
interested in learning how to build applications designed for the cloud.
A secondary audience is technical decision-makers who plan to choose whether to build their
applications using a cloud-native approach.
How you can use this guide
This guide begins by defining cloud native and introducing a reference application built using cloud-
native principles and technologies. Beyond these first two chapters, the rest of the book is broken up
into specific chapters focused on topics common to most cloud-native applications. You can jump to
any of these chapters to learn about cloud-native approaches to:
• Data and data access
• Communication patterns
• Scaling and scalability
• Application resiliency
• Monitoring and health
• Identity and security
• DevOps
This guide is available both in PDF form and online. Feel free to forward this document or links to its
online version to your team to help ensure common understanding of these topics. Most of these
topics benefit from a consistent understanding of the underlying principles and patterns, as well as
the trade-offs involved in decisions related to these topics. Our goal with this document is to equip
teams and their leaders with the information they need to make well-informed decisions for their
applications’ architecture, development, and hosting.
i Contents
Contents
Introduction to cloud-native applications............................................................................ 1
Cloud-native computing ..................................................................................................................................................3
What is Cloud Native?............................................................................................................................................................4
The pillars of cloud native................................................................................................................................................5
The cloud................................................................................................................................................................................5
Modern design.....................................................................................................................................................................6
Microservices ........................................................................................................................................................................8
Containers........................................................................................................................................................................... 11
Backing services................................................................................................................................................................ 14
Automation......................................................................................................................................................................... 16
Candidate apps for cloud native..................................................................................................................................... 18
Summary.............................................................................................................................................................................. 20
Introducing eShopOnContainers reference app ................................................................ 21
Features and requirements............................................................................................................................................... 22
Overview of the code .......................................................................................................................................................... 24
Understanding microservices........................................................................................................................................... 26
Mapping eShopOnContainers to Azure Services..................................................................................................... 26
Container orchestration and clustering................................................................................................................... 27
API Gateway ....................................................................................................................................................................... 27
Data ....................................................................................................................................................................................... 28
Event Bus ............................................................................................................................................................................. 29
Resiliency............................................................................................................................................................................. 29
Deploying eShopOnContainers to Azure.................................................................................................................... 29
Azure Kubernetes Service ............................................................................................................................................. 29
Deploying to Azure Kubernetes Service using Helm......................................................................................... 29
Azure Functions and Logic Apps (Serverless) ....................................................................................................... 31
Centralized configuration.................................................................................................................................................. 32
Azure App Configuration .............................................................................................................................................. 32
ii Contents
Azure Key Vault................................................................................................................................................................. 33
Configuration in eShop.................................................................................................................................................. 33
References........................................................................................................................................................................... 33
Scaling cloud-native applications........................................................................................ 35
Leveraging containers and orchestrators.................................................................................................................... 35
Challenges with monolithic deployments.............................................................................................................. 35
What are the benefits of containers and orchestrators?.................................................................................. 37
What are the scaling benefits?.................................................................................................................................... 39
What scenarios are ideal for containers and orchestrators?........................................................................... 41
When should you avoid using containers and orchestrators?....................................................................... 41
Development resources................................................................................................................................................. 41
Leveraging serverless functions ...................................................................................................................................... 45
What is serverless?........................................................................................................................................................... 46
What challenges are solved by serverless?............................................................................................................ 46
What is the difference between a microservice and a serverless function? ............................................. 46
What scenarios are appropriate for serverless?................................................................................................... 46
When should you avoid serverless?.......................................................................................................................... 47
Combining containers and serverless approaches.................................................................................................. 48
When does it make sense to use containers with serverless?........................................................................ 48
When should you avoid using containers with Azure Functions?................................................................ 48
How to combine serverless and Docker containers........................................................................................... 48
How to combine serverless and Kubernetes with KEDA .................................................................................. 49
Deploying containers in Azure ........................................................................................................................................ 49
Azure Container Registry .............................................................................................................................................. 49
ACR Tasks............................................................................................................................................................................ 51
Azure Kubernetes Service ............................................................................................................................................. 51
Azure Bridge to Kubernetes......................................................................................................................................... 52
Scaling containers and serverless applications......................................................................................................... 52
The simple solution: scaling up .................................................................................................................................. 52
Scaling out cloud-native apps .................................................................................................................................... 53
Other container deployment options........................................................................................................................... 54
When does it make sense to deploy to App Service for Containers?......................................................... 54
iii Contents
How to deploy to App Service for Containers...................................................................................................... 54
When does it make sense to deploy to Azure Container Instances? .......................................................... 54
How to deploy an app to Azure Container Instances........................................................................................ 54
References........................................................................................................................................................................... 55
Cloud-native communication patterns ............................................................................... 57
Communication considerations ...................................................................................................................................... 57
Front-end client communication.................................................................................................................................... 59
Simple Gateways .............................................................................................................................................................. 61
Azure Application Gateway.......................................................................................................................................... 62
Azure API Management................................................................................................................................................. 62
Real-time communication ............................................................................................................................................ 65
Service-to-service communication ................................................................................................................................ 66
Queries ................................................................................................................................................................................. 67
Commands.......................................................................................................................................................................... 70
Events.................................................................................................................................................................................... 73
gRPC........................................................................................................................................................................................... 79
What is gRPC? ................................................................................................................................................................... 79
gRPC Benefits .................................................................................................................................................................... 79
Protocol Buffers ................................................................................................................................................................ 80
gRPC support in .NET ..................................................................................................................................................... 80
gRPC usage......................................................................................................................................................................... 81
gRPC implementation .................................................................................................................................................... 82
Looking ahead................................................................................................................................................................... 84
Service Mesh communication infrastructure ............................................................................................................. 84
Summary.............................................................................................................................................................................. 85
Cloud-native data patterns .................................................................................................. 87
Database-per-microservice, why? .................................................................................................................................. 88
Cross-service queries........................................................................................................................................................... 89
Distributed transactions..................................................................................................................................................... 90
High volume data ................................................................................................................................................................. 92
CQRS ..................................................................................................................................................................................... 92
Event sourcing................................................................................................................................................................... 93
iv Contents
Relational vs. NoSQL data ................................................................................................................................................. 95
The CAP theorem ............................................................................................................................................................. 96
Considerations for relational vs. NoSQL systems................................................................................................ 98
Database as a Service..................................................................................................................................................... 98
Azure relational databases ........................................................................................................................................... 99
Azure SQL Database........................................................................................................................................................ 99
Open-source databases in Azure.............................................................................................................................100
NoSQL data in Azure ....................................................................................................................................................101
NewSQL databases........................................................................................................................................................105
Data migration to the cloud ......................................................................................................................................106
Caching in a cloud-native app.......................................................................................................................................107
Why?....................................................................................................................................................................................107
Caching architecture.....................................................................................................................................................107
Azure Cache for Redis ..................................................................................................................................................108
Elasticsearch in a cloud-native app .............................................................................................................................109
Summary............................................................................................................................................................................110
Cloud-native resiliency ....................................................................................................... 111
Application resiliency patterns ......................................................................................................................................112
Circuit breaker pattern.................................................................................................................................................114
Testing for resiliency.....................................................................................................................................................115
Azure platform resiliency.................................................................................................................................................115
Design with resiliency...................................................................................................................................................115
Design with redundancy..............................................................................................................................................116
Design for scalability.....................................................................................................................................................118
Built-in retry in services ...............................................................................................................................................119
Resilient communications................................................................................................................................................120
Service mesh ....................................................................................................................................................................120
Istio and Envoy................................................................................................................................................................122
Integration with Azure Kubernetes Services .......................................................................................................122
Monitoring and health........................................................................................................ 124
Observability patterns.......................................................................................................................................................124
When to use logging....................................................................................................................................................124
v Contents
Challenges with detecting and responding to potential app health issues ...........................................128
Challenges with reacting to critical problems in cloud-native apps..........................................................128
Logging with Elastic Stack...............................................................................................................................................129
Elastic Stack ......................................................................................................................................................................129
What are the advantages of Elastic Stack? ..........................................................................................................130
Logstash.............................................................................................................................................................................130
Elasticsearch .....................................................................................................................................................................131
Visualizing information with Kibana web dashboards ....................................................................................131
Installing Elastic Stack on Azure...............................................................................................................................132
References.........................................................................................................................................................................132
Monitoring in Azure Kubernetes Services.................................................................................................................132
Azure Monitor for Containers ...................................................................................................................................132
Log.Finalize() ....................................................................................................................................................................134
Azure Monitor......................................................................................................................................................................134
Gathering logs and metrics........................................................................................................................................135
Reporting data ................................................................................................................................................................135
Dashboards.......................................................................................................................................................................136
Alerts ...................................................................................................................................................................................138
References.........................................................................................................................................................................139
Cloud-native identity .......................................................................................................... 140
References .............................................................................................................................................................................140
Authentication and authorization in cloud-native apps .....................................................................................140
References.........................................................................................................................................................................141
Azure Active Directory ......................................................................................................................................................141
References.........................................................................................................................................................................141
IdentityServer for cloud-native applications............................................................................................................142
Common web app scenarios.....................................................................................................................................142
Getting started ................................................................................................................................................................143
Configuration...................................................................................................................................................................143
JavaScript clients ............................................................................................................................................................144
References.........................................................................................................................................................................144
Cloud-native security.......................................................................................................... 145
vi Contents
Azure security for cloud-native apps..........................................................................................................................145
Threat modeling .............................................................................................................................................................146
Principle of least privilege...........................................................................................................................................146
Penetration testing........................................................................................................................................................147
Monitoring........................................................................................................................................................................147
Securing the build..........................................................................................................................................................147
Building secure code ....................................................................................................................................................148
Built-in security ...............................................................................................................................................................148
Azure network infrastructure.....................................................................................................................................148
Role-based access control for restricting access to Azure resources........................................................150
Security Principals..........................................................................................................................................................150
Roles....................................................................................................................................................................................151
Scopes ................................................................................................................................................................................152
Deny ....................................................................................................................................................................................152
Checking access..............................................................................................................................................................152
Securing secrets..............................................................................................................................................................153
Azure Key Vault...............................................................................................................................................................153
Kubernetes........................................................................................................................................................................153
Encryption in transit and at rest ...............................................................................................................................154
Keeping secure................................................................................................................................................................158
DevOps ................................................................................................................................. 159
Azure DevOps.......................................................................................................................................................................160
GitHub Actions.....................................................................................................................................................................161
Source control......................................................................................................................................................................161
Repository per microservice ......................................................................................................................................162
Single repository ............................................................................................................................................................164
Standard directory structure......................................................................................................................................165
Task management ..............................................................................................................................................................165
CI/CD pipelines....................................................................................................................................................................167
Azure Builds......................................................................................................................................................................168
Azure DevOps releases ................................................................................................................................................170
Everybody gets a build pipeline...............................................................................................................................171
vii Contents
Versioning releases........................................................................................................................................................171
Feature flags .........................................................................................................................................................................171
Implementing feature flags........................................................................................................................................172
Infrastructure as code .......................................................................................................................................................173
Azure Resource Manager templates ......................................................................................................................173
Terraform...........................................................................................................................................................................175
Azure CLI Scripts and Tasks........................................................................................................................................175
Cloud Native Application Bundles ...............................................................................................................................176
DevOps Decisions ..........................................................................................................................................................178
References.........................................................................................................................................................................178
Summary: Architecting cloud-native apps ....................................................................... 179
1 CHAPTER 1 | Introduction to cloud-native applications
CHAPTER 1
Introduction to cloud-
native applications
Another day, at the office, working on “the next big thing.”
Your cellphone rings. It’s your friendly recruiter - the one who calls daily with exciting new
opportunities.
But this time it’s different: Start-up, equity, and plenty of funding.
The mention of the cloud, microservices, and cutting-edge technology pushes you over the edge.
Fast forward a few weeks and you’re now a new employee in a design session architecting a major
eCommerce application. You’re going to compete with the leading eCommerce sites.
How will you build it?
If you follow the guidance from past 15 years, you’ll most likely build the system shown in Figure 1.1.
Figure 1-1. Traditional monolithic design
You construct a large core application containing all of your domain logic. It includes modules such as
Identity, Catalog, Ordering, and more. They directly communicate with each other within a single
server process. The modules share a large relational database. The core exposes functionality via an
HTML interface and a mobile app.
Congratulations! You just created a monolithic application.
Not all is bad. Monoliths offer some distinct advantages. For example, they’re straightforward to…
2 CHAPTER 1 | Introduction to cloud-native applications
• build
• test
• deploy
• troubleshoot
• vertically scale
Many successful apps that exist today were created as monoliths. The app is a hit and continues to
evolve, iteration after iteration, adding more functionality.
At some point, however, you begin to feel uncomfortable. You find yourself losing control of the
application. As time goes on, the feeling becomes more intense, and you eventually enter a state
known as the Fear Cycle:
• The app has become so overwhelmingly complicated that no single person understands it.
• You fear making changes - each change has unintended and costly side effects.
• New features/fixes become tricky, time-consuming, and expensive to implement.
• Each release becomes as small as possible and requires a full deployment of the entire
application.
• One unstable component can crash the entire system.
• New technologies and frameworks aren’t an option.
• It’s difficult to implement agile delivery methodologies.
• Architectural erosion sets in as the code base deteriorates with never-ending “quick fixes.”
• Finally, the consultants come in and tell you to rewrite it.
Sound familiar?
Many organizations have addressed this monolithic fear cycle by adopting a cloud-native approach to
building systems. Figure 1-2 shows the same system built applying cloud-native techniques and
practices.
3 CHAPTER 1 | Introduction to cloud-native applications
Figure 1-2. Cloud-native design
Note how the application is decomposed across a set of small isolated microservices. Each service is
self-contained and encapsulates its own code, data, and dependencies. Each is deployed in a software
container and managed by a container orchestrator. Instead of a large relational database, each
service owns it own datastore, the type of which vary based upon the data needs. Note how some
services depend on a relational database, but other on NoSQL databases. One service stores its state
in a distributed cache. Note how all traffic routes through an API Gateway service that is responsible
for routing traffic to the core back-end services and enforcing many cross-cutting concerns. Most
importantly, the application takes full advantage of the scalability, availability, and resiliency features
found in modern cloud platforms.
Cloud-native computing
Hmm… We just used the term, Cloud Native. Your first thought might be, “What exactly does that
mean?” Another industry buzzword concocted by software vendors to market more stuff?"
Fortunately it’s far different, and hopefully this book will help convince you.
Within a short time, cloud native has become a driving trend in the software industry. It’s a new way
to construct large, complex systems. The approach takes full advantage of modern software
development practices, technologies, and cloud infrastructure. Cloud native changes the way you
design, implement, deploy, and operationalize systems.
Unlike the continuous hype that drives our industry, cloud native is for-real. Consider the Cloud Native
Computing Foundation (CNCF), a consortium of over 400 major corporations. Its charter is to make
4 CHAPTER 1 | Introduction to cloud-native applications
cloud-native computing ubiquitous across technology and cloud stacks. As one of the most influential
open-source groups, it hosts many of the fastest-growing open source-projects in GitHub. These
projects include Kubernetes, Prometheus, Helm, Envoy, and gRPC.
The CNCF fosters an ecosystem of open-source and vendor-neutrality. Following that lead, this book
presents cloud-native principles, patterns, and best practices that are technology agnostic. At the
same time, we discuss the services and infrastructure available in the Microsoft Azure cloud for
constructing cloud-native systems.
So, what exactly is Cloud Native? Sit back, relax, and let us help you explore this new world.
What is Cloud Native?
Stop what you’re doing and ask your colleagues to define the term “Cloud Native”. There’s a good
chance you’ll get several different answers.
Let’s start with a simple definition:
Cloud-native architecture and technologies are an approach to designing, constructing, and operating
workloads that are built in the cloud and take full advantage of the cloud computing model.
The Cloud Native Computing Foundation provides the official definition:
Cloud-native technologies empower organizations to build and run scalable applications in modern,
dynamic environments such as public, private, and hybrid clouds. Containers, service meshes,
microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable.
Combined with robust automation, they allow engineers to make high-impact changes frequently and
predictably with minimal toil.
Cloud native is about speed and agility. Business systems are evolving from enabling business
capabilities to weapons of strategic transformation that accelerate business velocity and growth. It’s
imperative to get new ideas to market immediately.
At the same time, business systems have also become increasingly complex with users demanding
more. They expect rapid responsiveness, innovative features, and zero downtime. Performance
problems, recurring errors, and the inability to move fast are no longer acceptable. Your users will visit
your competitor. Cloud-native systems are designed to embrace rapid change, large scale, and
resilience
Here are some companies who have implemented cloud-native techniques. Think about the speed,
agility, and scalability they’ve achieved.
Company Experience
Netflix Has 600+ services in production. Deploys 100 times per day.
Uber Has 1,000+ services in production. Deploys several thousand times each week.
WeChat Has 3,000+ services in production. Deploys 1,000 times a day.
5 CHAPTER 1 | Introduction to cloud-native applications
As you can see, Netflix, Uber, and, WeChat expose cloud-native systems that consist of many
independent services. This architectural style enables them to rapidly respond to market conditions.
They instantaneously update small areas of a live, complex application, without a full redeployment.
They individually scale services as needed.
The pillars of cloud native
The speed and agility of cloud native derive from many factors. Foremost is cloud infrastructure. But
there’s more: Five other foundational pillars shown in Figure 1-3 also provide the bedrock for cloud-
native systems.
Figure 1-3. Cloud-native foundational pillars
Let’s take some time to better understand the significance of each pillar.
The cloud
Cloud-native systems take full advantage of the cloud service model.
Designed to thrive in a dynamic, virtualized cloud environment, these systems make extensive use of
Platform as a Service (PaaS) compute infrastructure and managed services. They treat the underlying
infrastructure as disposable - provisioned in minutes and resized, scaled, or destroyed on demand –
via automation.
Consider the widely accepted DevOps concept of Pets vs. Cattle. In a traditional data center, servers
are treated as Pets: a physical machine, given a meaningful name, and cared for. You scale by adding
more resources to the same machine (scaling up). If the server becomes sick, you nurse it back to
health. Should the server become unavailable, everyone notices.
The Cattle service model is different. You provision each instance as a virtual machine or container.
They’re identical and assigned a system identifier such as Service-01, Service-02, and so on. You scale
by creating more of them (scaling out). When one becomes unavailable, nobody notices.
The cattle model embraces immutable infrastructure. Servers aren’t repaired or modified. If one fails or
requires updating, it’s destroyed and a new one is provisioned – all done via automation.
Cloud-native systems embrace the Cattle service model. They continue to run as the infrastructure
scales in or out with no regard to the machines upon which they’re running.
6 CHAPTER 1 | Introduction to cloud-native applications
The Azure cloud platform supports this type of highly elastic infrastructure with automatic scaling,
self-healing, and monitoring capabilities.
Modern design
How would you design a cloud-native app? What would your architecture look like? To what
principles, patterns, and best practices would you adhere? What infrastructure and operational
concerns would be important?
The Twelve-Factor Application
A widely accepted methodology for constructing cloud-based applications is the Twelve-Factor
Application. It describes a set of principles and practices that developers follow to construct
applications optimized for modern cloud environments. Special attention is given to portability across
environments and declarative automation.
While applicable to any web-based application, many practitioners consider Twelve-Factor a solid
foundation for building cloud-native apps. Systems built upon these principles can deploy and scale
rapidly and add features to react quickly to market changes.
The following table highlights the Twelve-Factor methodology:
Factor Explanation
1 - Code Base A single code base for each microservice, stored in its own repository. Tracked with
version control, it can deploy to multiple environments (QA, Staging, Production).
2 -
Dependencies
Each microservice isolates and packages its own dependencies, embracing changes
without impacting the entire system.
3 -
Configurations
Configuration information is moved out of the microservice and externalized
through a configuration management tool outside of the code. The same
deployment can propagate across environments with the correct configuration
applied.
4 - Backing
Services
Ancillary resources (data stores, caches, message brokers) should be exposed via an
addressable URL. Doing so decouples the resource from the application, enabling it
to be interchangeable.
5 - Build,
Release, Run
Each release must enforce a strict separation across the build, release, and run
stages. Each should be tagged with a unique ID and support the ability to roll back.
Modern CI/CD systems help fulfill this principle.
6 - Processes Each microservice should execute in its own process, isolated from other running
services. Externalize required state to a backing service such as a distributed cache
or data store.
7 - Port Binding Each microservice should be self-contained with its interfaces and functionality
exposed on its own port. Doing so provides isolation from other microservices.
7 CHAPTER 1 | Introduction to cloud-native applications
Factor Explanation
8 - Concurrency When capacity needs to increase, scale out services horizontally across multiple
identical processes (copies) as opposed to scaling-up a single large instance on the
most powerful machine available. Develop the application to be concurrent making
scaling out in cloud environments seamless.
9 - Disposability Service instances should be disposable. Favor fast startup to increase scalability
opportunities and graceful shutdowns to leave the system in a correct state. Docker
containers along with an orchestrator inherently satisfy this requirement.
10 - Dev/Prod
Parity
Keep environments across the application lifecycle as similar as possible, avoiding
costly shortcuts. Here, the adoption of containers can greatly contribute by
promoting the same execution environment.
11 - Logging Treat logs generated by microservices as event streams. Process them with an
event aggregator. Propagate log data to data-mining/log management tools like
Azure Monitor or Splunk and eventually to long-term archival.
12 - Admin
Processes
Run administrative/management tasks, such as data cleanup or computing
analytics, as one-off processes. Use independent tools to invoke these tasks from
the production environment, but separately from the application.
In the book, Beyond the Twelve-Factor App, author Kevin Hoffman details each of the original 12
factors (written in 2011). Additionally, he discusses three extra factors that reflect today’s modern
cloud application design.
New Factor Explanation
13 - API First Make everything a service. Assume your code will be consumed by a front-
end client, gateway, or another service.
14 - Telemetry On a workstation, you have deep visibility into your application and its
behavior. In the cloud, you don’t. Make sure your design includes the
collection of monitoring, domain-specific, and health/system data.
15 - Authentication/
Authorization
Implement identity from the start. Consider RBAC (role-based access control)
features available in public clouds.
We’ll refer to many of the 12+ factors in this chapter and throughout the book.
Azure Well-Architected Framework
Designing and deploying cloud-based workloads can be challenging, especially when implementing
cloud-native architecture. Microsoft provides industry standard best practices to help you and your
team deliver robust cloud solutions.
The Microsoft Well-Architected Framework provides a set of guiding tenets that can be used to
improve the quality of a cloud-native workload. The framework consists of five pillars of architecture
excellence:
8 CHAPTER 1 | Introduction to cloud-native applications
Tenets Description
Cost
management
Focus on generating incremental value early. Apply Build-Measure-Learn principles
to accelerate time to market while avoiding capital-intensive solutions. Using a pay-
as-you-go strategy, invest as you scale out, rather than delivering a large
investment up front.
Operational
excellence
Automate the environment and operations to increase speed and reduce human
error. Roll problem updates back or forward quickly. Implement monitoring and
diagnostics from the start.
Performance
efficiency
Efficiently meet demands placed on your workloads. Favor horizontal scaling
(scaling out) and design it into your systems. Continually conduct performance and
load testing to identify potential bottlenecks.
Reliability Build workloads that are both resilient and available. Resiliency enables workloads
to recover from failures and continue functioning. Availability ensures users access
to your workload at all times. Design applications to expect failures and recover
from them.
Security Implement security across the entire lifecycle of an application, from design and
implementation to deployment and operations. Pay close attention to identity
management, infrastructure access, application security, and data sovereignty and
encryption.
To get started, Microsoft provides a set of online assessments to help you assess your current cloud
workloads against the five well-architected pillars.
Microservices
Cloud-native systems embrace microservices, a popular architectural style for constructing modern
applications.
Built as a distributed set of small, independent services that interact through a shared fabric,
microservices share the following characteristics:
• Each implements a specific business capability within a larger domain context.
• Each is developed autonomously and can be deployed independently.
• Each is self-contained encapsulating its own data storage technology, dependencies, and
programming platform.
• Each runs in its own process and communicates with others using standard communication
protocols such as HTTP/HTTPS, gRPC, WebSockets, or AMQP.
• They compose together to form an application.
Figure 1-4 contrasts a monolithic application approach with a microservices approach. Note how the
monolith is composed of a layered architecture, which executes in a single process. It typically
consumes a relational database. The microservice approach, however, segregates functionality into
independent services, each with its own logic, state, and data. Each microservice hosts its own
datastore.
9 CHAPTER 1 | Introduction to cloud-native applications
Figure 1-4. Monolithic versus microservices architecture
Note how microservices promote the Processes principle from the Twelve-Factor Application,
discussed earlier in the chapter.
Factor #6 specifies “Each microservice should execute in its own process, isolated from other running
services.”
Why microservices?
Microservices provide agility.
Earlier in the chapter, we compared an eCommerce application built as a monolith to that with
microservices. In the example, we saw some clear benefits:
• Each microservice has an autonomous lifecycle and can evolve independently and deploy
frequently. You don’t have to wait for a quarterly release to deploy a new features or update.
You can update a small area of a live application with less risk of disrupting the entire system.
The update can be made without a full redeployment of the application.
• Each microservice can scale independently. Instead of scaling the entire application as a single
unit, you scale out only those services that require more processing power to meet desired
performance levels and service-level agreements. Fine-grained scaling provides for greater
control of your system and helps reduce overall costs as you scale portions of your system, not
everything.
An excellent reference guide for understanding microservices is .NET Microservices: Architecture for
Containerized .NET Applications. The book deep dives into microservices design and architecture. It’s
a companion for a full-stack microservice reference architecture available as a free download from
Microsoft.
Developing microservices
Microservices can be created upon any modern development platform.
10 CHAPTER 1 | Introduction to cloud-native applications
The Microsoft .NET platform is an excellent choice. Free and open source, it has many built-in features
that simplify microservice development. .NET is cross-platform. Applications can be built and run on
Windows, macOS, and most flavors of Linux.
.NET is highly performant and has scored well in comparison to Node.js and other competing
platforms. Interestingly, TechEmpower conducted an extensive set of performance benchmarks across
many web application platforms and frameworks. .NET scored in the top 10 - well above Node.js and
other competing platforms.
.NET is maintained by Microsoft and the .NET community on GitHub.
Microservice challenges
While distributed cloud-native microservices can provide immense agility and speed, they present
many challenges:
Communication
How will front-end client applications communicate with backed-end core microservices? Will you
allow direct communication? Or, might you abstract the back-end microservices with a gateway
facade that provides flexibility, control, and security?
How will back-end core microservices communicate with each other? Will you allow direct HTTP calls
that can increase coupling and impact performance and agility? Or might you consider decoupled
messaging with queue and topic technologies?
Communication is covered in the Cloud-native communication patterns chapter.
Resiliency
A microservices architecture moves your system from in-process to out-of-process network
communication. In a distributed architecture, what happens when Service B isn’t responding to a
network call from Service A? Or, what happens when Service C becomes temporarily unavailable and
other services calling it become blocked?
Resiliency is covered in the Cloud-native resiliency chapter.
Distributed Data
By design, each microservice encapsulates its own data, exposing operations via its public interface. If
so, how do you query data or implement a transaction across multiple services?
Distributed data is covered in the Cloud-native data patterns chapter.
Secrets
How will your microservices securely store and manage secrets and sensitive configuration data?
Secrets are covered in detail Cloud-native security.
Random documents with unrelated
content Scribd suggests to you:
Meru,” say the texts.
Meru was its Amnion, and the other mountains were its Chorion,
adds a verse in Vishnu Purâna.768
In the same way is man born in his mother's womb. As Brahmâ is
surrounded, in exoteric traditions, by seven layers within and seven
without the Mundane Egg, so is the embryo (the first or the seventh layer,
according to the end from which we begin to count). Thus, just as
Esotericism in its Cosmogony enumerates seven inner and seven outer
layers, so Physiology notes the contents of the uterus as seven also,
although it is completely ignorant of this being a copy of what takes place
in the Universal Matrix. These contents are:
1. Embryo. 2. Amniotic Fluid, immediately surrounding the Embryo. 3.
Amnion, a membrane derived from the Fœtus, which contains the fluid. 4.
Umbilical Vesicle, which serves to convey nourishment originally [pg 441]
to the Embryo and to nourish it. 5. Allantois, a protrusion from the
Embryo in the form of a closed bag, which spreads itself between 3 and
7, in the midst of 6, and which, after being specialized into the Placenta,
serves to conduct nourishment to the Embryo. 6. Interspace between 3
and 7 (the Amnion and Chorion), filled with an albuminous fluid. 7.
Chorion, or outer layer.
Now, each of these seven contents severally corresponds with, and is
formed after, an antetype, one on each of the seven planes of being, with
which in their turn correspond the seven states of Matter and all other
forces, sensational or functional, in Nature.
The following is a bird's-eye view of the seven correspondential contents
of the wombs of Nature and of Woman. We may contrast them thus:
(1) Cosmic Process: The mathematical Point, called the “Cosmic
Seed,” the Monad of Leibnitz; which contains the whole Universe, as
the acorn the oak. This is the first bubble on the surface of
boundless homogeneous Substance, or Space, the bubble of
differentiation in its incipient stage. It is the beginning of the Orphic
or Brahmâ's Egg. It corresponds in Astrology and Astronomy to the
Sun.
Human Process: The terrestrial Embryo, which contains in it the
future man with all his potentialities. In the series of principles of the
human system it is the Âtman, or the super-spiritual principle, just as
in the physical Solar System it is the Sun.
(2) Cosmic Process: The vis vitæ of our solar system exudes from
the Sun. Human Process: The Amniotic Fluid exudes from the
Embryo.
(a) Cosmic Process: It is called, when referred to the higher planes,
Âkâsha. Human Process: It is called, on the plane of matter,
Prâna.769
(b) Cosmic Process: It proceeds from the ten “divinities,” the ten
numbers of the Sun, which is itself the “Perfect Number.” These are
called Dis—in reality Space—the forces spread in Space, three of
which are contained in the Sun's Âtman, or seventh principle, and
seven are the rays shot out by the Sun.
Human Process: It proceeds, taking its source in the universal One
Life, from the heart of man and Buddhi, over which the Seven Solar
Rays (Gods) preside.
[pg 442]
(3) Cosmic Process: The Ether of Space, which, in its external aspect,
is the plastic crust which is supposed to envelope the Sun. On the
higher plane it is the whole Universe, as the third differentiation of
evolving Substance, Mûlaprakriti becoming Prakriti.
Human Process: The Amnion, the membrane containing the Amniotic
Fluid and enveloping the Embryo. After the birth of man it becomes
the third layer, so to say, of his magneto-vital aura.
(a) Cosmic Process: It corresponds mystically to the manifested
Mahat, or the Intellect or Soul of the World. Human Process: Manas,
the third principle (counting from above), or the Human Soul in Man.
(4) Cosmic Process: The sidereal contents of Ether, the substantial
parts of it, unknown to Modern Science, represented as follows.
Human Process: Umbilical Vesicle, serving, as Science teaches, to
nourish the Embryo originally, but, as Occult Science avers, to carry
to the Fœtus by osmosis the cosmic influences extraneous to the
mother.
(a) Cosmic Process: In Occult and Kabalistic Mysteries, by
Elementals. Human Process: In the grown man these become the
feeders of Kâma, over which they preside.
(b) Cosmic Process: In physical Astronomy, by meteors, comets, and
all kinds of casual and phenomenal cosmic bodies. Human Process:
In the physical man, his passions and emotions, the moral meteors
and comets of human nature.
(5) Cosmic Process: Life currents in Ether, having their origin in the
Sun: the canals through which the vital principle of that Ether (the
blood of the Cosmic Body) passes to nourish everything on the Earth
and on the other Planets: from the minerals, which are thus made to
grow and become specialized, from the plants, which are thus fed, to
animal and man, to whom life is thus imparted.
Human Process: The Allantois, a protrusion from the Embryo, which
spreads itself between the Amnion and Chorion; it is supposed to
conduct the nourishment from the mother to the Embryo. It
corresponds to the life-principle, Prâna or Jîva.
[pg 443]
(6) Cosmic Process: The double radiation, psychic and physical,
which radiates from the Cosmic Seed and expands around the whole
Kosmos, as well as around the Solar System and every Planet. In
Occultism it is called the upper divine, and the lower material, Astral
Light.
Human Process: The Allantois is divided into two layers. The
interspace between the Amnion and the Chorion contains the
Allantois and also an albuminous fluid.770
(7) Cosmic Process: The outer crust of every sidereal body, the Shell
of the Mundane Egg, or the sphere of our Solar System, of our Earth,
and of every man and animal. In sidereal space, Ether proper; on the
terrestrial plane, Air, which again is built in seven layers.
Human Process: The Chorion, or the Zona Pellucida, the globular
object called Blastodermic Vesicle, the outer and the inner layers of
the membrane of which go to form the physical man. The outer, or
ectoderm, forms his epidermis; the inner, or endoderm, his muscles,
bones, etc. Man's skin, again, is composed of seven layers.
(a) Cosmic Process: The primordial potential world-stuff becomes
(for the Manvantaric period) the permanent globe or globes. Human
Process: The “primitive” becomes the “permanent” Chorion.
Even in the evolution of the Races we see the same order as in Nature
and Man.771
Placental animal-man became such only after the separation
of sexes in the Third Root-Race. In the physiological evolution, the
placenta is fully formed and functional only after the third month of
uterine life.
[pg 444]
Let us put aside such human conceptions as a personal God, and hold to
the purely divine, to that which underlies all and everything in boundless
Nature. It is called by its Sanskrit Esoteric name in the Vedas, Tat (or
That), a term for the unknowable Rootless Root. If we do so, we may
answer these seven questions of the Esoteric Catechism thus:
(1) Q.—What is the Eternal Absolute?
A.—That.
(2) Q.—How came Kosmos into being?
A.—Through That.
(3) Q.—How, or what will it be when it falls back into Pralaya?
A.—In That.
(4) Q.—Whence all the animate, and suppositionally, the
“inanimate”nature?
A.—From That.
(5) Q.—What is the Substance and Essence of which the Universe is
formed?
A.—That.
(6) Q.—Into what has it been and will be again and again resolved?
A.—Into That.
(7) Q.—Is That then both the instrumental and material cause of the
Universe?
A.—What else is it or can it be than That?
As the Universe, the Macrocosm and the Microcosm,772
are ten, why
should we divide Man into seven “principles”? This is the reason why the
perfect number ten is divided into two: in their completeness, i.e., super-
spiritually and physically, the forces are ten: to wit, three on the
subjective and inconceivable, and seven on the objective plane. Bear in
mind that I am now giving you the description of the two opposite poles:
(a) the primordial Triangle, which, as soon as it has reflected itself in the
“Heavenly Man,” the highest of the lower seven—disappears, returning
into “Silence and Darkness”; and (b) the astral paradigmatic man, whose
Monad (Âtmâ) is also represented by a triangle, as it has to become a
ternary in conscious Devachanic interludes. The purely terrestrial man
being reflected in the universe of Matter, so to say, upside down, the
upper Triangle, wherein the creative ideation and the subjective
potentiality of the formative faculty resides, [pg 445] is shifted in the man
of clay below the seven. Thus three of the ten, containing in the
archetypal world only ideative and paradigmatical potentiality, i.e.,
existing in possibility, not in action, are in fact one. The potency of
formative creation resides in the Logos, the synthesis of the seven Forces
or Rays, which becomes forthwith the Quaternary, the sacred Tetraktys.
This process is repeated in man, in whom the lower physical triangle
becomes, in conjunction with the female One, the male-female creator, or
generator. The same on a still lower plane in the animal world. A mystery
above, a mystery below, truly.
This is how the upper and highest, and the lower and most animal, stand
in mutual relation.
Diagram I
1st—Macrocosm and Its 3, 7, or 10 Centres of Creative Forces
A. B. C. The Unknowable
A. Sexless, Unmanifested Logos
B. Potential Wisdom
C. Universal Ideation
a. Creative Logos
b. Eternal Substance
c. Spirit
a. b. c. This is Pradhâna, undifferentiated matter in Sânkhya philosophy,
or Good, Evil and Chaotic Darkness (Sattva, Rajas, and Tamas),
neutralizing each other. When differentiated, they become the Seven
Creative Potencies: Spirit, Substance and Fire stimulating Matter to form
itself.
D. The Spiritual Forces acting in Matter
2nd.—Microcosm (the Inner Man) and his 3, 7, or 10 Centres of Potential
Forces
(ÂTMAN, although exoterically reckoned as the seventh principle, is no
individual principle at all, and belongs to the Universal Soul; 7 is the
AURIC EGG, the Magnetic Sphere round every human and animal being.)
1. Buddhi, the vehicle of Âtmâ.
2. Manas, the vehicle of Buddhi.
3. Lower Manas (the Upper and Lower Manas are two aspects of one and
the same principle) and
4. Kâma Rûpa, its vehicle.
5. Prâna, Life, and
6. Linga Sharira, its vehicle
I. II. III. are the Three Hypostases of Âtman, its contact with Nature and
Man being the Fourth, making it a Quaternary, or Tetraktys, the Higher
self.
1. 2. 3. 4. 5. 6. These six principles, acting on four different planes, and
having their Auric Envelope on the seventh (vide infra), are those used by
the Adepts of the Right-Hand, or White Magicians.
3rd.—Microcosm (the Physical Man) and his 10 Orifices, or centres of
Action
1. (Buddhi) Right Eye
3. (Lower Manas) Right Ear
5. (Life Principle) Right Nostril
7. The Organ of the Creative Logos, the Mouth
8. 9. 10. As this Lower Ternary has a direct connection with the Higher
Âtmic Triad and its three aspects (creative, preservative and destructive,
or rather regenerative), the abuse of the corresponding functions is the
most terrible of Karmic Sins—the Sin against the Holy Ghost with the
Christians.
2. (Manas) Left Eye
4. (Kâma Rûpa) Left Ear
6. (Life Vehicle) Left Nostril
7. The Paradigm of the 10th (creative) orifice in the Lower Triad.
These Physical Organs are used only by Dugpas in Black Magic.
In this diagram, we see that physical man (or his body) does not share in
the direct pure waves of the divine Essence which flows from the One in
Three, the Unmanifested, through the Manifested Logos (the upper face
in the diagram). Purusha, the primeval Spirit, touches the human head
and stops there. But the Spiritual Man (the synthesis of the seven
principles) is directly connected with it. And here a few words ought to be
said about the usual exoteric enumeration of the principles. At first an
approximate division only was made and given out. Esoteric Buddhism
begins with Âtmâ, the seventh, and ends with the Physical Body, the first.
Now neither Âtmâ, which is no individual “principle,” but a radiation from
and one with the Unmanifested Logos; nor the Body, which is the material
rind, or shell, of the Spiritual Man, can be, in strict truth, referred to as
“principles.” Moreover, the chief “principle” of all, one not even mentioned
heretofore, is the “Luminous Egg” (Hiranyagarbha), or the invisible
magnetic sphere in which every man is enveloped.773
It is the direct
emanation: (a) from the Âtmic Ray in its triple aspect of Creator,
Preserver and Destroyer (Regenerator); and (b) from Buddhi-Manas. The
seventh aspect of this individual Aura is the faculty of assuming the form
of its body and becoming the “Radiant,” the Luminous Augoeides. It is
this, strictly speaking, which at times becomes the form called Mâyâvi
Rûpa. Therefore, as explained in the second face of the diagram (the
astral man), the Spiritual Man consists of only five [pg 446] principles, as
taught by the Vedântins,774
who substitute, tacitly, for the physical this
sixth, or Auric, Body, and merge the dual Manas (the dual mind, or
consciousness) into one. Thus they speak of five Koshas (sheaths or
principles), and call Âtmâ the sixth yet no “principle.” This is the secret of
the late Subba Row's criticism of the division in Esoteric Buddhism. But let
the student now learn the true Esoteric enumeration.
The reason why public mention of the Auric Body was not permitted was
on account of its being so sacred. It is this Body which, at death,
assimilates the essence of Buddhi and Manas and becomes the vehicle of
these spiritual principles, which are not objective, and then, with the full
radiation of Âtmâ upon it ascends as Manas-Taijasi into the Devachanic
state. Therefore is it called by many names. It is the Sûtrâtmâ, the silver
“thread” which “incarnates” from the beginning of Manvantara to the end,
stringing upon itself the pearls of human existence, in other words, the
spiritual aroma of every personality it follows through the pilgrimage of
life.775
It is also the material from which the Adept forms his Astral Bodies,
from the Augoeides and the Mâyâvi Rûpa downwards. After the death of
man, when its most ethereal particles have drawn into themselves the
spiritual principles of Buddhi and the Upper Manas, and are illuminated
with the radiance of Âtmâ, the Auric Body remains either in the
Devachanic state of consciousness, or, in the case of a full Adept, prefers
the state of a Nirmânakâya, that is, one who has so purified his whole
system that he is above even the divine illusion of a Devachanî. Such an
Adept remains in the astral (invisible) plane connected with our earth,
and henceforth moves and lives in the possession of all his principles
except the Kâma Rûpa and Physical Body. In the case of the Devachanî,
the Linga Sharîra—the alter ego of the body, which during life is within
the physical envelope while the radiant aura is without—strengthened by
the material particles which this aura leaves behind, remains close to the
dead body and outside it, and soon fades away. In the case of the full
Adept, the body alone becomes subject to dissolution, while the centre of
that force which was the seat of desires and passions, disappears with its
cause—the animal body. But during the life of the latter all these centres
are more or less active and in constant correspondence [pg 447] with
their prototypes, the cosmic centres, and their microcosms, the principles.
It is only through these cosmic and spiritual centres that the physical
centres (the upper seven orifices and the lower triad) can benefit by their
Occult interaction, for these orifices, or openings, are channels conducting
into the body the influences that the will of man attracts and uses, viz.,
the cosmic forces.
This will has, of course, to act primarily through the spiritual principles. To
make this clearer, let us take an example. In order to stop pain, let us say
in the right eye, you have to attract to it the potent magnetism from that
cosmic principle which corresponds to this eye and also to Buddhi. Create,
by a powerful will effort, an imaginary line of communication between the
right eye and Buddhi, locating the latter as a centre in the same part of
the head. This line, though you may call it “imaginary,” is, once you
succeed in seeing it with your mental eye and give it a shape and colour,
in truth as good as real. A rope in a dream is not and yet is. Moreover,
according to the prismatic colour with which you endow your line, so will
the influence act. Now Buddhi and Mercury correspond with each other,
and both are yellow, or radiant and golden coloured. In the human
system, the right eye corresponds with Buddhi and Mercury; and the left
with Manas and Venus or Lucifer. Thus, if your line is golden or silvery, it
will stop the pain; if red, it will increase it, for red is the colour of Kâma
and corresponds with Mars. Mental or Christian Scientists have stumbled
upon the effects without understanding the causes. Having found by
chance the secret of producing such results owing to mental abstraction,
they attribute them to their union with God (whether a personal or
impersonal God they know best), whereas it is simply the effect of one or
another principle. However it may be, they are on the path of discovery,
although they must remain wandering for a long time to come.
Let not Esoteric students commit the same mistake. It has often been
explained that neither the cosmic planes of substance nor even the
human principles—with the exception of the lowest material plane or
world and the physical body, which, as has been said, are no
“principles,”—can be located or thought of as being in Space and Time. As
the former are seven in One, so are we seven in One—that same absolute
Soul of the World, which is both Matter and non-Matter, Spirit and non-
Spirit, Being and non-Being. Impress yourselves well with this idea, all
those of you who would study the mysteries of Self.
Remember that with our physical senses alone at our command, none [pg
448] of us can hope to reach beyond gross Matter. We can do so only
through one or another of our seven spiritual senses, either by training,
or if one is a born Seer. Yet even a clairvoyant possessed of such
faculties, if not an Adept, no matter how honest and sincere he may be,
will, through his ignorance of the truths of Occult Science, be led by the
visions he sees in the Astral Light only to mistake for God or Angels the
denizens of those spheres of which he may occasionally catch a glimpse,
as witness Swedenborg and others.
These seven senses of ours correspond with every other septenate in
nature and in ourselves. Physically, though invisibly, the human Auric
Envelope (the amnion of the physical man in every age of life) has seven
layers, just as Cosmic Space and our physical epidermis have. It is this
Aura which, according to our mental and physical state of purity or
impurity, either opens for us vistas into other worlds, or shuts us out
altogether from anything but this three-dimensional world of Matter.
Each of our seven physical senses (two of which are still unknown to
profane Science), and also of our seven states of consciousness—viz.: (1)
waking; (2) waking-dreaming; (3) natural sleeping; (4) induced or trance-
sleep; (5) psychic; (6) super-psychic; and (7) purely spiritual—
corresponds with one of the seven Cosmic Planes, develops and uses one
of the seven super-senses, and is connected directly, in its use on the
terrestro-spiritual plane, with the cosmic and divine centre of force that
gave it birth, and which is its direct creator. Each is also connected with,
and under the direct influence of, one of the seven sacred Planets.776
These belonged to the Lesser Mysteries, whose followers were called
Mystai (the veiled), seeing that they were allowed to perceive things only
through a mist, as it were “with the eyes closed”; while the Initiates or
“Seers” of the Greater Mysteries were called Epoptai (those who see
things unveiled). It was the latter only who were taught the true
mysteries of the Zodiac and the relations and correspondences between
its twelve signs (two secret) and the ten human orifices. The latter are
now of course ten in the female, and only nine in the male; but this is
merely an external difference. In the second volume of this work it is
stated that till the end of the Third Root-Race (when androgynous man
separated into male and female) the ten orifices existed in the
hermaphrodite, first potentially, then [pg 449] functionally. The evolution
of the human embryo shows this. For instance, the only opening formed
at first is the buccal cavity, “a cloaca communicating with the anterior
extremity of the intestine.” These become later the mouth and the
posterior orifice: the Logos differentiating and emanating gross matter on
the lower plane, in Occult parlance. The difficulty which some students
will experience in reconciling the correspondences between the Zodiac
and the orifices can be easily explained. Magic is coëval with the Third
Root-Race, which began by creating through Kriyâshakti and ended by
generating its species in the present way.777
Woman, being left with the
full or perfect cosmic number 10 (the divine number of Jehovah), was
deemed higher and more spiritual than man. In Egypt, in days of old, the
marriage service contained an article that the woman should be the “lady
of the lord,” and real lord over him, the husband pledging himself to be
“obedient to his wife” for the production of alchemical results such as the
Elixir of Life and the Philosopher's Stone, for the spiritual help of the
woman was needed by the male Alchemist. But woe to the Alchemist who
should take this in the dead-letter sense of physical union. Such sacrilege
would become Black Magic and be followed by certain failure. The true
Alchemist of old took aged women to help him, carefully avoiding the
young ones; and if any of them happened to be married they treated
their wives for months both before and during their operations as sisters.
The error of crediting the Ancients with knowing only ten of the zodiacal
signs is explained in Isis Unveiled.778
The Ancients did know of twelve, but
viewed these signs differently from ourselves. They took neither Virgo nor
Scorpio singly into consideration, but regarded them as two in one, since
they were made to refer directly and symbolically to the primeval dual
man and his separation into sexes. During the reformation of the Zodiac,
Libra was added as the twelfth sign, though it is simply an equilibrating
sign, at the turning point—the mystery of separated man.
Let the student learn all this well. Meanwhile we have to recapitulate
what has been said.
(1) Each human being is an incarnation of his God, in other words, one
with his “Father in Heaven,” just as Jesus, an Initiate, is made to say. As
many men on earth, so many Gods in Heaven; and yet these [pg 450]
Gods are in reality One, for at the end of every period of activity, they are
withdrawn, like the rays of the setting sun, into the Parent Luminary, the
Non-Manifested Logos, which in its turn is merged into the One Absolute.
Shall we call these “Fathers” of ours, whether individually or collectively,
and under any circumstances, our personal God? Occultism answers,
Never. All that an average man can know of his “Father” is what he
knows of himself, through and within himself. The Soul of his “Heavenly
Father” is incarnated in him. This Soul is himself, if he be successful in
assimilating the Divine Individuality while in his physical, animal shell. As
to the Spirit thereof, as well expect to be heard by the Absolute. Our
prayers and supplications are vain, unless to potential words we add
potent acts, and make the Aura which surrounds each one of us so pure
and divine that the God within us may act outwardly, or in other words,
become as it were an extraneous Potency. Thus have Initiates, Saints,
and very holy and pure men been enabled to help others as well as
themselves in the hour of need, and produce what are foolishly called
“miracles,” each by the help and with the aid of the God within himself,
which he alone has enabled to act on the outward plane.
(2) The word Aum or Om, which corresponds to the upper Triangle, if
pronounced by a very holy and pure man, will draw out, or awaken, not
only the less exalted Potencies residing in the planetary spaces and
elements, but even his Higher Self, or the “Father” within him.
Pronounced by an averagely good man, in the correct way, it will help to
strengthen him morally, especially if between two “Aums” he meditates
intently upon the Aum within him, concentrating all his attention upon the
ineffable glory. But woe to the man who pronounces it after the
commission of some far-reaching sin: he will only thereby attract to his
own impure photosphere invisible Presences and Forces which could not
otherwise break through the Divine Envelope.
Aum is the original of Amen. Now, Amen is not a Hebrew term, but, like
the word Halleluiah, was borrowed by the Jews and Greeks from the
Chaldees. The latter word is often found repeated in certain magical
inscriptions upon cups and urns among the Babylonian and Ninevean
relics. Amen does not mean “so be it,” or “verily,” but signified in hoary
antiquity almost the same as Aum. The Jewish Tanaïm (Initiates) used it
for the same reason as the Âryan Adepts use Aum, and with a like
success, the numerical value of AMeN in Hebrew [pg 451] letters being
91, the same as the full value of YHVH,779
26, and ADoNaY, 65, or 91.
Both words mean the affirmation of the being, or existence, of the sexless
“Lord” within us.
(3) Esoteric Science teaches that every sound in the visible world
awakens its corresponding sound in the invisible realms, and arouses to
action some force or other on the Occult side of Nature. Moreover, every
sound corresponds to a colour and a number (a potency spiritual, psychic
or physical) and to a sensation on some plane. All these find an echo in
every one of the so-far developed elements, and even on the terrestrial
plane, in the Lives that swarm in the terrene atmosphere, thus prompting
them to action.
Thus a prayer, unless pronounced mentally and addressed to one's
“Father” in the silence and solitude of one's “closet,” must have more
frequently disastrous than beneficial results, seeing that the masses are
entirely ignorant of the potent effects which they thus produce. To
produce good effects, the prayer must be uttered by “one who knows
how to make himself heard in silence,” when it is no longer a prayer, but
becomes a command. Why is Jesus shown to have forbidden his hearers
to go to the public synagogues? Surely every praying man was not a
hypocrite and a liar, nor a Pharisee who loved to be seen praying by
people! He had a motive, we must suppose: the same motive which
prompts the experienced Occultist to prevent his pupils from going into
crowded places now as then, from entering churches, séance rooms, etc.,
unless they are in sympathy with the crowd.
There is one piece of advice to be given to beginners, who cannot help
going into crowds—one which may appear superstitious, but which in the
absence of Occult knowledge will be found efficacious. As well known to
good Astrologers, the days of the week are not in the order of those
planets whose names they bear. The fact is that the ancient Hindus and
Egyptians divided the day into four parts, each day being under the
protection (as ascertained by practical magic) of a planet; and every day,
as correctly asserted by Dion Cassius, received the name of the planet
which ruled and protected its first portion. Let the student protect himself
from the “Powers of the Air” (Elementals) which throng public places, by
wearing either a ring containing some jewel of the colour of the presiding
planet, or else of the metal sacred to it. But the best protection is a clear
conscience and a firm desire to benefit Humanity.
[pg 452]
The Planets, The Days of the Week and Their
Corresponding Colours and Metals.
[Transcriber's Note: This table was a wide pull-out insert into the book,
with more columns than modern readers can display. It has been
reformatted into several tables of more manageable width.]
These Correspondences are from the Objective, Terrestrial Plane.
Âtman is no Number, and corresponds to no visible Planet, for it proceeds
from the Spiritual Sun; nor does it bear any relation either to Sound,
Colour, or the rest, for it includes them all.
As the Human Principles have no Numbers per se, but only correspond to
Numbers, Sounds, Colours, etc., they are not enumerated here in the
order used for exoteric purposes.
NUMBERS METALS. PLANETS.
1 and 10. Physical
Man's Key-note.
Iron.
Mars. The Planet of
Generation.
2. Life Spiritual and
Life Physical.
Gold.
The Sun. The Giver of
Life physically.
Spiritually and
esoterically the
substitute for the
inter-Mercurial Planet,
a sacred and secret
planet with the
ancients.
3. Because Buddhi
is (so to speak)
between Âtmâ and
Manas, and forms
with the seventh, or
Auric Envelope, the
Devachanic Triad.
Mercury. Mixes
with Sulphur, as
Buddhi is mixed
with the Flame of
Spirit (See
Alchemical
Definitions.)
Mercury. The
Messenger and the
Interpreter of the
Gods.
4. The middle
principle—between
the purely material
and purely spiritual
triads. The
conscious part of
animal man.
Lead. Saturn.
5. Tin. Jupiter.
6.
Copper. When
alloyed becomes
Bronze (the dual
principle).
Venus. The Morning
and the Evening Star.
7. Contains in itself
the reflection of
Septenary Man.
Silver.
The Moon. The
Patent of the Earth.
NUMBERS
THE HUMAN
PRINCIPLES.
DAYS OF THE WEEK.
1 and 10.
Kâma Rûpa. The
vehicle or seat of the
Animal Instincts and
Passions.
Tuesday. Dies Martis, or
Tiw.
2. Prâna or Jîva. Life. Sunday. Dies Solss, or Sun.
3.
Buddhi. Spiritual Soul,
or Âtmic Ray; vehicle
of Âtmâ.
Wednesday. Dies Mercurii,
or Woden. Day of Buddha
in the South, end of Woden
in the North—Gods of
Wisdom.
4.
Kâma Manas. The
Lower Mind, or Animal
Soul.
Saturday. Dies Saturns, or
Saturn.
5. Auric Envelope.
Thursday. Dies Jovis, or
Thor.
6.
Manas. The Higher
Mind, or Human Soul.
Friday. Dies Veneris, or
Friga.
7.
Linga Sharîra. The
Astral Double of Man,
the Parent of the
Physical Man.
NUMBERS COLOURS. SOUND. Musical Scale..
1 and 10. 1 Red. Sa or Do.
2. 2 Orange. Ri or Re.
3. 3. Yellow. Ga or Mi.
4. 4. Green. Ma or Fa.
5. 5. Blue. Pa or Sol.
6. 6. Indigo or Dark Blue. Da or La.
7. 7. Violet. Ni or Si.
In the accompanying diagram the days of the week do not stand in their
usual order, though they are placed in their correct sequence as
determined by the order of the colours in the solar spectrum and the
corresponding colours of their ruling planets. The fault of the confusion in
the order of the days revealed by this comparison lies at the door of the
early Christians. Adopting from the Jews their lunar months, they tried to
blend them with the solar planets, and so made a mess of it; for the
order of the days of the week as it now stands does not follow the order
of the planets.
Now, the Ancients arranged the planets in the following order: Moon,
Mercury, Venus, Sun, Mars, Jupiter, Saturn, counting the Sun as a planet
for exoteric purposes. Again, the Egyptians and Indians, the two oldest
nations, divided their day into four parts, each of which was under the
protection and rule of a planet. In course of time each day came to be
called by the name of that planet which ruled its first portion—the
morning. Now, when they arranged their week, the Christians proceeded
as follows: they wanted to make the day of the Sun, or Sunday, the
seventh, so they named the days of the week by taking every fourth
planet in turn; e.g., beginning with the Moon (Monday), they counted
thus: Moon, Mercury, Venus, Sun, Mars; thus Tuesday, the day whose first
portion was ruled by Mars, became the second day of the week; and so
on. It should be remembered also that the Moon, like the Sun, is a
substitute for a secret planet.
The present division of the solar year was made several centuries later
than the beginning of our era; and our week is not that of the Ancients
and the Occultists. The septenary division of the four parts of the lunar
phases is as old as the world, and originated with the people who
reckoned time by the lunar months. The Hebrews never used it, for they
counted only the seventh day, the Sabbath, though the second chapter of
Genesis seems to speak of it. Till the days of the Cæsars there is no trace
of a week of seven days among any nation save the Hindus. From India it
passed to the Arabs, and reached Europe with Christianity. The Roman
week consisted of eight days, and the Athenian of ten.780
Thus one of the
numberless contradictions [pg 453] and fallacies of Christendom is the
adoption of the Indian septenary week of the lunar reckoning, and the
preservation at the same time of the mythological names of the planets.
Nor do modern Astrologers give the correspondences of the days and
planets and their colours correctly; and while Occultists can give good
reason for every detail of their own tables of colours, etc., it is doubtful
whether the Astrologers can do the same.
To close this first Paper, let me say that the readers must in all necessity
be separated into two broad divisions: those who have not quite rid
themselves of the usual sceptical doubts, but who long to ascertain how
much truth there may be in the claims of the Occultists; and those others
who, having freed themselves from the trammels of Materialism and
Relativity, feel that true and real bliss must be sought only in the
knowledge and personal experience of that which the Hindu Philosopher
calls the Brahmavidyâ, and the Buddhist Arhat the realization of
Âdibuddha, the primeval Wisdom. Let the former pick out and study from
these Papers only those explanations of the phenomena of life which
profane Science is unable to give them. Even with such limitations, they
will find by the end of a year or two that they will have learned more than
all their Universities and Colleges can teach them. As to the sincere
believers, they will be rewarded by seeing their faith transformed into
knowledge. True knowledge is of Spirit and in Spirit alone, and cannot be
acquired in any other way except through the region of the higher mind,
the only plane from which we can penetrate the depths of the all-
pervading Absoluteness. He who carries out only those laws established
by human minds, who lives that life which is prescribed by the code of
mortals and their fallible legislation, chooses as his guiding star a beacon
which shines on the ocean of Mâyâ, or of temporary delusions, and lasts
for but one incarnation. These laws are necessary for the life and welfare
of physical man alone. He has chosen a pilot who directs him through the
shoals of one existence, a master who parts with him, however, on the
threshold of death. How much happier that man who, while strictly
performing on the temporary objective plane the duties of daily life,
carrying out each and every law of his country, and rendering, in short, to
Cæsar what is Cæsar's, leads in reality a spiritual and permanent
existence, a life with no breaks of continuity, no gaps, no interludes, [pg
454] not even during those periods which are the halting-places of the
long pilgrimage of purely spiritual life. All the phenomena of the lower
human mind disappear like the curtain of a proscenium, allowing him to
live in the region beyond it, the plane of the noumenal, the one reality. If
man by suppressing, if not destroying, his selfishness and personality,
only succeeds in knowing himself as he is behind the veil of physical
Mâyâ, he will soon stand beyond all pain, all misery, and beyond all the
wear and tear of change, which is the chief originator of pain. Such a
man will be physically of Matter, he will move surrounded by Matter, and
yet he will live beyond and outside it. His body will be subject to change,
but he himself will be entirely without it, and will experience everlasting
life even while in temporary bodies of short duration. All this may be
achieved by the development of unselfish universal love of Humanity, and
the suppression of personality, or selfishness, which is the cause of all sin,
and consequently of all human sorrow.
[pg 455]
Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor
Paper II. An Explanation.
In view of the abstruse nature of the subjects dealt with, the present
Paper will begin with an explanation of some points which remained
obscure in the preceding one, as well as of some statements in which
there was an appearance of contradiction.
Astrologers, of whom there are many among the Esotericists, are likely to
be puzzled by some statements distinctly contradicting their teachings;
whilst those who know nothing of the subject may perhaps find
themselves opposed at the outset by those who have studied the exoteric
systems of the Kabalah and Astrology. For let it be distinctly known,
nothing of that which is printed broadcast, and available to every student
in public libraries or museums, is really Esoteric, but is either mixed with
deliberate “blinds,” or cannot be understood and studied with profit
without a complete glossary of Occult terms.
The following teachings and explanations, therefore, may be useful to the
student in assisting him to formulate the teaching given in the preceding
Paper.
In Diagram I. it will be observed that the 3, 7, and 10 centres are
respectively as follows:
(a) The 3 pertain to the spiritual world of the Absolute, and therefore to
the three higher principles in Man.
(b) The 7 belong to the spiritual, psychic, and physical worlds and to the
body of man. Physics, metaphysics and hyper-physics are the triad that
symbolizes man on this plane.
(c) The 10, or the sum total of these, is the Universe as a whole, in all its
aspects, and also its Microcosm—Man, with his ten orifices.
Laying aside, for the moment, the Higher Decad (Kosmos) and the [pg
456] Lower Decad (Man), the first three numbers of the separate sevens
have a direct reference to the Spirit, Soul and Auric Envelope of the
human being, as well as to the higher supersensual world. The lower four,
or the four aspects, belong to Man also, as well as to the Universal
Kosmos, the whole being synthesized by the Absolute.
If these three discrete or distributive degrees of Being be conceived,
according to the Symbology of all the Eastern Religions, as contained in
one Ovum, or Egg, the name of that Egg will be Svabhâvat, or the All-
Being on the manifested plane. This Universe has, in truth, neither centre
nor periphery; but in the individual and finite mind of man it has such a
definition, the natural consequence of the limitations of human thought.
In Diagram II., as already stated therein, no notice need be taken of the
numbers used in the left-hand column, as these refer only to the
Hierarchies of the Colours and Sounds on the metaphysical plane, and are
not the characteristic numbers of the human principles or of the planets.
The human principles elude enumeration, because each man differs from
every other, just as no two blades of grass on the whole earth are
absolutely alike. Numbering is here a question of spiritual progress and
the natural predominance of one principle over another. With one man it
may be Buddhi that stands as number one; with another, if he be a
bestial sensualist, the Lower Manas. With one the physical body, or
perhaps Prâna, the life principle, will be on the first and highest plane, as
would be the case in an extremely healthy man, full of vitality; with
another it may come as the sixth or even seventh downward. Again, the
colours and metals corresponding to the planets and human principles, as
will be observed, are not those known exoterically to modern Astrologers
and Western Occultists.
Let us see whence the modern Astrologer got his notions about the
correspondence of planets, metals and colours. And here we are
reminded of the modern Orientalist, who, judging by appearances credits
the ancient Akkadians (and also the Chaldæans, Hindus and Egyptians)
with the crude notion that the Universe, and in like manner the earth,
was like an inverted, bell-shaped bowl! This he demonstrates by pointing
to the symbolical representations of some Akkadian inscriptions and to
the Assyrian carvings. It is, however, no place here to explain how
mistaken is the Assyriologist, for all such representations are simply
symbolical of the Khargakkurra, the World-Mountain, or Meru, and relate
only to the North Pole, the Land of the [pg 457] Gods. Now, the Assyrians
arranged their exoteric teaching about the planets and their
correspondences as follows:
Diagram II.
Numbers. Planets. Metals. Colours.
Solar Days of
Week.
1. Saturn. Lead. Black.
Saturday.
(Whence
Sabbath,781
in honour of
Jehovah.)
2. Jupiter. Tin.
White,
but as
often
Purple or
Orange.
Thursday.
3. Mars. Iron. Red. Tuesday.
4. Sun. Gold.
Yellow-
golden.
Sunday.
5. Venus. Copper.
Green or
Yellow.
Friday.
6. Mercury. Quicksilver. Blue. Wednesday.
7. Moon. Silver.
Silver-
white.
Monday.
This is the arrangement now adopted by Christian Astrologers, with the
exception of the order of the days of the week, of which, by associating
the solar planetary names with the lunar weeks, they have made a sore
mess, as has been already shown in Paper I. This is the Ptolemaic
geocentric system, which represents the Universe as in the following
diagram, showing our Earth in the centre of the Universe, and the Sun a
Planet, the fourth in number.
And if the Christian chronology and order of the days of the week are
being daily denounced as being based on an entirely wrong astronomical
foundation, it is high time to begin a reform also in Astrology built on
such lines, and coming to us entirely from the Chaldæan and Assyrian
exoteric mob.
But the correspondences given in these Papers are purely Esoteric. [pg
458] For this reason it follows that when the Planets of the Solar System
are named or symbolized (as in Diagram II.) it must not be supposed that
the planetary bodies themselves are referred to, except as types on a
purely physical plane of the septenary nature of the psychic and spiritual
worlds. A material planet can correspond only to a material something.
Thus when Mercury is said to correspond to the right eye, it does not
mean that the objective planet has any influence on the right optic organ,
but that both stand rather as corresponding mystically through Buddhi.
Man derives his Spiritual Soul (Buddhi) from the essence of the Mânasa
Putra, the Sons of Wisdom, who are the Divine Beings (or Angels) ruling
and presiding over the planet Mercury.
In the same way Venus, Manas and the left eye are set down as
correspondences. Exoterically, there is, in reality, no such association of
physical eyes and physical planets; but Esoterically there is; for the right
eye is the “Eye of Wisdom,” i.e., it corresponds magnetically with that
Occult centre in the brain which we call the “Third Eye”;782
while the left
corresponds with the intellectual brain, or those cells which are the organ
on the physical plane of the thinking faculty. The kabalistic triangle of
Kether, Chokmah and Binah shows this. Chokmah and Binah, or Wisdom
and Intelligence, the Father and Mother, or, again, the Father and Son,
are on the same plane and reäct mutually on one another.
When the individual consciousness is turned inward, a conjunction of
Manas and Buddhi takes place. In the spiritually regenerated man this
conjunction is permanent, the Higher Manas clinging to Buddhi beyond
the threshold of Devachan, and the Soul, or rather the Spirit, which
should not be confounded with Âtmâ, the Super-Spirit, is then said to
have the “Single Eye.” Esoterically, in other words, the “Third Eye” is
active. Now Mercury is called Hermes, and Venus, Aphrodite, and thus
their conjunction in man on the psycho-physical plane gives him the
name of the Hermaphrodite, or Androgyne. The absolutely Spiritual Man
is, however, entirely disconnected from sex. The Spiritual Man
corresponds directly with the higher “coloured circles,” the Divine Prism
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

More Related Content

PDF
Migrating_to_Cloud-Native_App_Architectures_Pivotal (2)
PDF
Migrating to cloud-native_app_architectures_pivotal
PDF
Migrating_to_Cloud-Native_App_Architectures_Pivotal
PDF
Migrating_to_Cloud-Native_App_Architectures_Pivotal (2)
PPTX
What is Cloud Native Explained?
PDF
Dapr for-net-developers
PDF
Cloud Native IT Transformation - Whitepaper by RapidValue
PPTX
Cloud Native development.pptx
Migrating_to_Cloud-Native_App_Architectures_Pivotal (2)
Migrating to cloud-native_app_architectures_pivotal
Migrating_to_Cloud-Native_App_Architectures_Pivotal
Migrating_to_Cloud-Native_App_Architectures_Pivotal (2)
What is Cloud Native Explained?
Dapr for-net-developers
Cloud Native IT Transformation - Whitepaper by RapidValue
Cloud Native development.pptx

Similar to Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor (20)

PDF
Mastering the Cloud-Native Maze: A Blog Journey
PPTX
Information on Cloud-native Applications
PDF
All you need to know about cloud native development for your business.pdf
PDF
Cloud Native Architecture: Its Benefits and Key Components
PDF
Dapr-for-NET-Developers Course Technical (6).pdf
PDF
Exploring Cloud Native Architecture: Its Benefits And Key Components
PDF
Cloud Native Applications Unlocking Innovation and Growth
PDF
Securing the Cloud Native stack
PPTX
Agile architectures in a modern cloud-native ecosystem
PDF
Agile Architecture in a Modern Cloud-Native Ecosystem
PDF
DZone’s 2016 Guide To Building And Deploying Applications In The Cloud
PDF
Securing the Cloud Native Stack
PDF
.NET Cloud-Native Bootcamp
PDF
Unveiling the Advantages and Core Elements of Cloud Native Architecture
PDF
.NET Cloud-Native Bootcamp- Los Angeles
PPTX
CloudWorld: What Does Cloud-Native Mean Anyway?
PPTX
GIDS_what does_cloud-native_mean_anyway?
PDF
Architecture 2020 - eComputing 2019-07-01
PDF
Building Scalable and Resilient Cloud-Native Apps - Fiorano
PPTX
Cloud-Native-Applications-The-Future-of-Development.pptx
Mastering the Cloud-Native Maze: A Blog Journey
Information on Cloud-native Applications
All you need to know about cloud native development for your business.pdf
Cloud Native Architecture: Its Benefits and Key Components
Dapr-for-NET-Developers Course Technical (6).pdf
Exploring Cloud Native Architecture: Its Benefits And Key Components
Cloud Native Applications Unlocking Innovation and Growth
Securing the Cloud Native stack
Agile architectures in a modern cloud-native ecosystem
Agile Architecture in a Modern Cloud-Native Ecosystem
DZone’s 2016 Guide To Building And Deploying Applications In The Cloud
Securing the Cloud Native Stack
.NET Cloud-Native Bootcamp
Unveiling the Advantages and Core Elements of Cloud Native Architecture
.NET Cloud-Native Bootcamp- Los Angeles
CloudWorld: What Does Cloud-Native Mean Anyway?
GIDS_what does_cloud-native_mean_anyway?
Architecture 2020 - eComputing 2019-07-01
Building Scalable and Resilient Cloud-Native Apps - Fiorano
Cloud-Native-Applications-The-Future-of-Development.pptx
Ad

Recently uploaded (20)

PDF
LIFE & LIVING TRILOGY- PART (1) WHO ARE WE.pdf
PDF
Race Reva University – Shaping Future Leaders in Artificial Intelligence
PDF
Complications of Minimal Access-Surgery.pdf
PDF
FOISHS ANNUAL IMPLEMENTATION PLAN 2025.pdf
PDF
FORM 1 BIOLOGY MIND MAPS and their schemes
PDF
Environmental Education MCQ BD2EE - Share Source.pdf
PDF
Τίμαιος είναι φιλοσοφικός διάλογος του Πλάτωνα
PPTX
Unit 4 Computer Architecture Multicore Processor.pptx
PDF
LIFE & LIVING TRILOGY - PART - (2) THE PURPOSE OF LIFE.pdf
PPTX
Climate Change and Its Global Impact.pptx
PPTX
Introduction to pro and eukaryotes and differences.pptx
PDF
Empowerment Technology for Senior High School Guide
PDF
Journal of Dental Science - UDMY (2022).pdf
PDF
BP 505 T. PHARMACEUTICAL JURISPRUDENCE (UNIT 2).pdf
PDF
Literature_Review_methods_ BRACU_MKT426 course material
PPTX
Module on health assessment of CHN. pptx
PDF
David L Page_DCI Research Study Journey_how Methodology can inform one's prac...
PDF
IP : I ; Unit I : Preformulation Studies
PDF
HVAC Specification 2024 according to central public works department
PDF
1.3 FINAL REVISED K-10 PE and Health CG 2023 Grades 4-10 (1).pdf
LIFE & LIVING TRILOGY- PART (1) WHO ARE WE.pdf
Race Reva University – Shaping Future Leaders in Artificial Intelligence
Complications of Minimal Access-Surgery.pdf
FOISHS ANNUAL IMPLEMENTATION PLAN 2025.pdf
FORM 1 BIOLOGY MIND MAPS and their schemes
Environmental Education MCQ BD2EE - Share Source.pdf
Τίμαιος είναι φιλοσοφικός διάλογος του Πλάτωνα
Unit 4 Computer Architecture Multicore Processor.pptx
LIFE & LIVING TRILOGY - PART - (2) THE PURPOSE OF LIFE.pdf
Climate Change and Its Global Impact.pptx
Introduction to pro and eukaryotes and differences.pptx
Empowerment Technology for Senior High School Guide
Journal of Dental Science - UDMY (2022).pdf
BP 505 T. PHARMACEUTICAL JURISPRUDENCE (UNIT 2).pdf
Literature_Review_methods_ BRACU_MKT426 course material
Module on health assessment of CHN. pptx
David L Page_DCI Research Study Journey_how Methodology can inform one's prac...
IP : I ; Unit I : Preformulation Studies
HVAC Specification 2024 according to central public works department
1.3 FINAL REVISED K-10 PE and Health CG 2023 Grades 4-10 (1).pdf
Ad

Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor

  • 1. Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor download https://ebookbell.com/product/architecting-cloud-native-net-apps- for-azure-v103-v103-robert-vettor-54231780 Explore and download more ebooks at ebookbell.com
  • 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Architecting Cloud Native Net Apps For Azure V102 Robert Vettor Steve Ardalis Smith https://ebookbell.com/product/architecting-cloud-native-net-apps-for- azure-v102-robert-vettor-steve-ardalis-smith-34627612 Architecting Cloudnative Serverless Solutions Design Build And Operate Serverless Solutions On Cloud And Open Source Platforms Safeer Cm https://ebookbell.com/product/architecting-cloudnative-serverless- solutions-design-build-and-operate-serverless-solutions-on-cloud-and- open-source-platforms-safeer-cm-50501596 Architecting Cloud Native Applications Kamal Arora Erik Farr https://ebookbell.com/product/architecting-cloud-native-applications- kamal-arora-erik-farr-27028914 Architecting Cloud Native Applications Design Highperforming And Costeffective Applications For The Cloud Kamal Arora https://ebookbell.com/product/architecting-cloud-native-applications- design-highperforming-and-costeffective-applications-for-the-cloud- kamal-arora-47032738
  • 3. Architecting Cloudnative Serverless Solutions Design Build And Operate Serverless Solutions On Cloud And Open Source Platforms Cm https://ebookbell.com/product/architecting-cloudnative-serverless- solutions-design-build-and-operate-serverless-solutions-on-cloud-and- open-source-platforms-cm-56267610 Managing Cloud Native Data On Kubernetes Architecting Cloud Native Data Services Using Open Source Technology 1st Edition Jeff Carpenter https://ebookbell.com/product/managing-cloud-native-data-on- kubernetes-architecting-cloud-native-data-services-using-open-source- technology-1st-edition-jeff-carpenter-53833350 Managing Cloud Native Data On Kubernetes Architecting Cloud Native Data Services Using Open Source Technology Jeff Carpenter https://ebookbell.com/product/managing-cloud-native-data-on- kubernetes-architecting-cloud-native-data-services-using-open-source- technology-jeff-carpenter-56280926 Managing Cloud Native Data On Kubernetes Architecting Cloud Native Data Services Using Open Source Technology 1st Edition Jeff Carpenter https://ebookbell.com/product/managing-cloud-native-data-on- kubernetes-architecting-cloud-native-data-services-using-open-source- technology-1st-edition-jeff-carpenter-56280924 Architecting Cloud Computing Solutions Build Cloud Strategies That Align Technology And Economics While Effectively Managing Risk 1st Edition Kevin L Jackson https://ebookbell.com/product/architecting-cloud-computing-solutions- build-cloud-strategies-that-align-technology-and-economics-while- effectively-managing-risk-1st-edition-kevin-l-jackson-47173342
  • 6. EDITION v1.0.3 Refer changelog for the book updates and community contributions. PUBLISHED BY Microsoft Developer Division, .NET, and Visual Studio product teams A division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2023 by Microsoft Corporation All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. This book is provided “as-is” and expresses the author’s views and opinions. The views, opinions, and information expressed in this book, including URL and other Internet website references, may change without notice. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. Microsoft and the trademarks listed at https://www.microsoft.com on the “Trademarks” webpage are trademarks of the Microsoft group of companies. Mac and macOS are trademarks of Apple Inc. The Docker whale logo is a registered trademark of Docker, Inc. Used by permission. All other marks and logos are property of their respective owners. Authors: Rob Vettor, Principal MTC (Microsoft Technology Center) Architect for Cloud App Innovation - thinkingincloudnative.com, Microsoft Steve “ardalis” Smith, Software Architect and Trainer - Ardalis.com Participants and Reviewers: Cesar De la Torre, Principal Program Manager, .NET team, Microsoft Nish Anil, Senior Program Manager, .NET team, Microsoft Jeremy Likness, Senior Program Manager, .NET team, Microsoft Cecil Phillip, Senior Cloud Advocate, Microsoft Sumit Ghosh, Principal Consultant at Neudesic Editors: Maira Wenzel, Program Manager, .NET team, Microsoft
  • 7. David Pine, Senior Content Developer, .NET docs, Microsoft Version This guide has been written to cover .NET 7 version along with many additional updates related to the same “wave” of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET 7 release. Who should use this guide The audience for this guide is mainly developers, development leads, and architects who are interested in learning how to build applications designed for the cloud. A secondary audience is technical decision-makers who plan to choose whether to build their applications using a cloud-native approach. How you can use this guide This guide begins by defining cloud native and introducing a reference application built using cloud- native principles and technologies. Beyond these first two chapters, the rest of the book is broken up into specific chapters focused on topics common to most cloud-native applications. You can jump to any of these chapters to learn about cloud-native approaches to: • Data and data access • Communication patterns • Scaling and scalability • Application resiliency • Monitoring and health • Identity and security • DevOps This guide is available both in PDF form and online. Feel free to forward this document or links to its online version to your team to help ensure common understanding of these topics. Most of these topics benefit from a consistent understanding of the underlying principles and patterns, as well as the trade-offs involved in decisions related to these topics. Our goal with this document is to equip teams and their leaders with the information they need to make well-informed decisions for their applications’ architecture, development, and hosting.
  • 8. i Contents Contents Introduction to cloud-native applications............................................................................ 1 Cloud-native computing ..................................................................................................................................................3 What is Cloud Native?............................................................................................................................................................4 The pillars of cloud native................................................................................................................................................5 The cloud................................................................................................................................................................................5 Modern design.....................................................................................................................................................................6 Microservices ........................................................................................................................................................................8 Containers........................................................................................................................................................................... 11 Backing services................................................................................................................................................................ 14 Automation......................................................................................................................................................................... 16 Candidate apps for cloud native..................................................................................................................................... 18 Summary.............................................................................................................................................................................. 20 Introducing eShopOnContainers reference app ................................................................ 21 Features and requirements............................................................................................................................................... 22 Overview of the code .......................................................................................................................................................... 24 Understanding microservices........................................................................................................................................... 26 Mapping eShopOnContainers to Azure Services..................................................................................................... 26 Container orchestration and clustering................................................................................................................... 27 API Gateway ....................................................................................................................................................................... 27 Data ....................................................................................................................................................................................... 28 Event Bus ............................................................................................................................................................................. 29 Resiliency............................................................................................................................................................................. 29 Deploying eShopOnContainers to Azure.................................................................................................................... 29 Azure Kubernetes Service ............................................................................................................................................. 29 Deploying to Azure Kubernetes Service using Helm......................................................................................... 29 Azure Functions and Logic Apps (Serverless) ....................................................................................................... 31 Centralized configuration.................................................................................................................................................. 32 Azure App Configuration .............................................................................................................................................. 32
  • 9. ii Contents Azure Key Vault................................................................................................................................................................. 33 Configuration in eShop.................................................................................................................................................. 33 References........................................................................................................................................................................... 33 Scaling cloud-native applications........................................................................................ 35 Leveraging containers and orchestrators.................................................................................................................... 35 Challenges with monolithic deployments.............................................................................................................. 35 What are the benefits of containers and orchestrators?.................................................................................. 37 What are the scaling benefits?.................................................................................................................................... 39 What scenarios are ideal for containers and orchestrators?........................................................................... 41 When should you avoid using containers and orchestrators?....................................................................... 41 Development resources................................................................................................................................................. 41 Leveraging serverless functions ...................................................................................................................................... 45 What is serverless?........................................................................................................................................................... 46 What challenges are solved by serverless?............................................................................................................ 46 What is the difference between a microservice and a serverless function? ............................................. 46 What scenarios are appropriate for serverless?................................................................................................... 46 When should you avoid serverless?.......................................................................................................................... 47 Combining containers and serverless approaches.................................................................................................. 48 When does it make sense to use containers with serverless?........................................................................ 48 When should you avoid using containers with Azure Functions?................................................................ 48 How to combine serverless and Docker containers........................................................................................... 48 How to combine serverless and Kubernetes with KEDA .................................................................................. 49 Deploying containers in Azure ........................................................................................................................................ 49 Azure Container Registry .............................................................................................................................................. 49 ACR Tasks............................................................................................................................................................................ 51 Azure Kubernetes Service ............................................................................................................................................. 51 Azure Bridge to Kubernetes......................................................................................................................................... 52 Scaling containers and serverless applications......................................................................................................... 52 The simple solution: scaling up .................................................................................................................................. 52 Scaling out cloud-native apps .................................................................................................................................... 53 Other container deployment options........................................................................................................................... 54 When does it make sense to deploy to App Service for Containers?......................................................... 54
  • 10. iii Contents How to deploy to App Service for Containers...................................................................................................... 54 When does it make sense to deploy to Azure Container Instances? .......................................................... 54 How to deploy an app to Azure Container Instances........................................................................................ 54 References........................................................................................................................................................................... 55 Cloud-native communication patterns ............................................................................... 57 Communication considerations ...................................................................................................................................... 57 Front-end client communication.................................................................................................................................... 59 Simple Gateways .............................................................................................................................................................. 61 Azure Application Gateway.......................................................................................................................................... 62 Azure API Management................................................................................................................................................. 62 Real-time communication ............................................................................................................................................ 65 Service-to-service communication ................................................................................................................................ 66 Queries ................................................................................................................................................................................. 67 Commands.......................................................................................................................................................................... 70 Events.................................................................................................................................................................................... 73 gRPC........................................................................................................................................................................................... 79 What is gRPC? ................................................................................................................................................................... 79 gRPC Benefits .................................................................................................................................................................... 79 Protocol Buffers ................................................................................................................................................................ 80 gRPC support in .NET ..................................................................................................................................................... 80 gRPC usage......................................................................................................................................................................... 81 gRPC implementation .................................................................................................................................................... 82 Looking ahead................................................................................................................................................................... 84 Service Mesh communication infrastructure ............................................................................................................. 84 Summary.............................................................................................................................................................................. 85 Cloud-native data patterns .................................................................................................. 87 Database-per-microservice, why? .................................................................................................................................. 88 Cross-service queries........................................................................................................................................................... 89 Distributed transactions..................................................................................................................................................... 90 High volume data ................................................................................................................................................................. 92 CQRS ..................................................................................................................................................................................... 92 Event sourcing................................................................................................................................................................... 93
  • 11. iv Contents Relational vs. NoSQL data ................................................................................................................................................. 95 The CAP theorem ............................................................................................................................................................. 96 Considerations for relational vs. NoSQL systems................................................................................................ 98 Database as a Service..................................................................................................................................................... 98 Azure relational databases ........................................................................................................................................... 99 Azure SQL Database........................................................................................................................................................ 99 Open-source databases in Azure.............................................................................................................................100 NoSQL data in Azure ....................................................................................................................................................101 NewSQL databases........................................................................................................................................................105 Data migration to the cloud ......................................................................................................................................106 Caching in a cloud-native app.......................................................................................................................................107 Why?....................................................................................................................................................................................107 Caching architecture.....................................................................................................................................................107 Azure Cache for Redis ..................................................................................................................................................108 Elasticsearch in a cloud-native app .............................................................................................................................109 Summary............................................................................................................................................................................110 Cloud-native resiliency ....................................................................................................... 111 Application resiliency patterns ......................................................................................................................................112 Circuit breaker pattern.................................................................................................................................................114 Testing for resiliency.....................................................................................................................................................115 Azure platform resiliency.................................................................................................................................................115 Design with resiliency...................................................................................................................................................115 Design with redundancy..............................................................................................................................................116 Design for scalability.....................................................................................................................................................118 Built-in retry in services ...............................................................................................................................................119 Resilient communications................................................................................................................................................120 Service mesh ....................................................................................................................................................................120 Istio and Envoy................................................................................................................................................................122 Integration with Azure Kubernetes Services .......................................................................................................122 Monitoring and health........................................................................................................ 124 Observability patterns.......................................................................................................................................................124 When to use logging....................................................................................................................................................124
  • 12. v Contents Challenges with detecting and responding to potential app health issues ...........................................128 Challenges with reacting to critical problems in cloud-native apps..........................................................128 Logging with Elastic Stack...............................................................................................................................................129 Elastic Stack ......................................................................................................................................................................129 What are the advantages of Elastic Stack? ..........................................................................................................130 Logstash.............................................................................................................................................................................130 Elasticsearch .....................................................................................................................................................................131 Visualizing information with Kibana web dashboards ....................................................................................131 Installing Elastic Stack on Azure...............................................................................................................................132 References.........................................................................................................................................................................132 Monitoring in Azure Kubernetes Services.................................................................................................................132 Azure Monitor for Containers ...................................................................................................................................132 Log.Finalize() ....................................................................................................................................................................134 Azure Monitor......................................................................................................................................................................134 Gathering logs and metrics........................................................................................................................................135 Reporting data ................................................................................................................................................................135 Dashboards.......................................................................................................................................................................136 Alerts ...................................................................................................................................................................................138 References.........................................................................................................................................................................139 Cloud-native identity .......................................................................................................... 140 References .............................................................................................................................................................................140 Authentication and authorization in cloud-native apps .....................................................................................140 References.........................................................................................................................................................................141 Azure Active Directory ......................................................................................................................................................141 References.........................................................................................................................................................................141 IdentityServer for cloud-native applications............................................................................................................142 Common web app scenarios.....................................................................................................................................142 Getting started ................................................................................................................................................................143 Configuration...................................................................................................................................................................143 JavaScript clients ............................................................................................................................................................144 References.........................................................................................................................................................................144 Cloud-native security.......................................................................................................... 145
  • 13. vi Contents Azure security for cloud-native apps..........................................................................................................................145 Threat modeling .............................................................................................................................................................146 Principle of least privilege...........................................................................................................................................146 Penetration testing........................................................................................................................................................147 Monitoring........................................................................................................................................................................147 Securing the build..........................................................................................................................................................147 Building secure code ....................................................................................................................................................148 Built-in security ...............................................................................................................................................................148 Azure network infrastructure.....................................................................................................................................148 Role-based access control for restricting access to Azure resources........................................................150 Security Principals..........................................................................................................................................................150 Roles....................................................................................................................................................................................151 Scopes ................................................................................................................................................................................152 Deny ....................................................................................................................................................................................152 Checking access..............................................................................................................................................................152 Securing secrets..............................................................................................................................................................153 Azure Key Vault...............................................................................................................................................................153 Kubernetes........................................................................................................................................................................153 Encryption in transit and at rest ...............................................................................................................................154 Keeping secure................................................................................................................................................................158 DevOps ................................................................................................................................. 159 Azure DevOps.......................................................................................................................................................................160 GitHub Actions.....................................................................................................................................................................161 Source control......................................................................................................................................................................161 Repository per microservice ......................................................................................................................................162 Single repository ............................................................................................................................................................164 Standard directory structure......................................................................................................................................165 Task management ..............................................................................................................................................................165 CI/CD pipelines....................................................................................................................................................................167 Azure Builds......................................................................................................................................................................168 Azure DevOps releases ................................................................................................................................................170 Everybody gets a build pipeline...............................................................................................................................171
  • 14. vii Contents Versioning releases........................................................................................................................................................171 Feature flags .........................................................................................................................................................................171 Implementing feature flags........................................................................................................................................172 Infrastructure as code .......................................................................................................................................................173 Azure Resource Manager templates ......................................................................................................................173 Terraform...........................................................................................................................................................................175 Azure CLI Scripts and Tasks........................................................................................................................................175 Cloud Native Application Bundles ...............................................................................................................................176 DevOps Decisions ..........................................................................................................................................................178 References.........................................................................................................................................................................178 Summary: Architecting cloud-native apps ....................................................................... 179
  • 15. 1 CHAPTER 1 | Introduction to cloud-native applications CHAPTER 1 Introduction to cloud- native applications Another day, at the office, working on “the next big thing.” Your cellphone rings. It’s your friendly recruiter - the one who calls daily with exciting new opportunities. But this time it’s different: Start-up, equity, and plenty of funding. The mention of the cloud, microservices, and cutting-edge technology pushes you over the edge. Fast forward a few weeks and you’re now a new employee in a design session architecting a major eCommerce application. You’re going to compete with the leading eCommerce sites. How will you build it? If you follow the guidance from past 15 years, you’ll most likely build the system shown in Figure 1.1. Figure 1-1. Traditional monolithic design You construct a large core application containing all of your domain logic. It includes modules such as Identity, Catalog, Ordering, and more. They directly communicate with each other within a single server process. The modules share a large relational database. The core exposes functionality via an HTML interface and a mobile app. Congratulations! You just created a monolithic application. Not all is bad. Monoliths offer some distinct advantages. For example, they’re straightforward to…
  • 16. 2 CHAPTER 1 | Introduction to cloud-native applications • build • test • deploy • troubleshoot • vertically scale Many successful apps that exist today were created as monoliths. The app is a hit and continues to evolve, iteration after iteration, adding more functionality. At some point, however, you begin to feel uncomfortable. You find yourself losing control of the application. As time goes on, the feeling becomes more intense, and you eventually enter a state known as the Fear Cycle: • The app has become so overwhelmingly complicated that no single person understands it. • You fear making changes - each change has unintended and costly side effects. • New features/fixes become tricky, time-consuming, and expensive to implement. • Each release becomes as small as possible and requires a full deployment of the entire application. • One unstable component can crash the entire system. • New technologies and frameworks aren’t an option. • It’s difficult to implement agile delivery methodologies. • Architectural erosion sets in as the code base deteriorates with never-ending “quick fixes.” • Finally, the consultants come in and tell you to rewrite it. Sound familiar? Many organizations have addressed this monolithic fear cycle by adopting a cloud-native approach to building systems. Figure 1-2 shows the same system built applying cloud-native techniques and practices.
  • 17. 3 CHAPTER 1 | Introduction to cloud-native applications Figure 1-2. Cloud-native design Note how the application is decomposed across a set of small isolated microservices. Each service is self-contained and encapsulates its own code, data, and dependencies. Each is deployed in a software container and managed by a container orchestrator. Instead of a large relational database, each service owns it own datastore, the type of which vary based upon the data needs. Note how some services depend on a relational database, but other on NoSQL databases. One service stores its state in a distributed cache. Note how all traffic routes through an API Gateway service that is responsible for routing traffic to the core back-end services and enforcing many cross-cutting concerns. Most importantly, the application takes full advantage of the scalability, availability, and resiliency features found in modern cloud platforms. Cloud-native computing Hmm… We just used the term, Cloud Native. Your first thought might be, “What exactly does that mean?” Another industry buzzword concocted by software vendors to market more stuff?" Fortunately it’s far different, and hopefully this book will help convince you. Within a short time, cloud native has become a driving trend in the software industry. It’s a new way to construct large, complex systems. The approach takes full advantage of modern software development practices, technologies, and cloud infrastructure. Cloud native changes the way you design, implement, deploy, and operationalize systems. Unlike the continuous hype that drives our industry, cloud native is for-real. Consider the Cloud Native Computing Foundation (CNCF), a consortium of over 400 major corporations. Its charter is to make
  • 18. 4 CHAPTER 1 | Introduction to cloud-native applications cloud-native computing ubiquitous across technology and cloud stacks. As one of the most influential open-source groups, it hosts many of the fastest-growing open source-projects in GitHub. These projects include Kubernetes, Prometheus, Helm, Envoy, and gRPC. The CNCF fosters an ecosystem of open-source and vendor-neutrality. Following that lead, this book presents cloud-native principles, patterns, and best practices that are technology agnostic. At the same time, we discuss the services and infrastructure available in the Microsoft Azure cloud for constructing cloud-native systems. So, what exactly is Cloud Native? Sit back, relax, and let us help you explore this new world. What is Cloud Native? Stop what you’re doing and ask your colleagues to define the term “Cloud Native”. There’s a good chance you’ll get several different answers. Let’s start with a simple definition: Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model. The Cloud Native Computing Foundation provides the official definition: Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. Cloud native is about speed and agility. Business systems are evolving from enabling business capabilities to weapons of strategic transformation that accelerate business velocity and growth. It’s imperative to get new ideas to market immediately. At the same time, business systems have also become increasingly complex with users demanding more. They expect rapid responsiveness, innovative features, and zero downtime. Performance problems, recurring errors, and the inability to move fast are no longer acceptable. Your users will visit your competitor. Cloud-native systems are designed to embrace rapid change, large scale, and resilience Here are some companies who have implemented cloud-native techniques. Think about the speed, agility, and scalability they’ve achieved. Company Experience Netflix Has 600+ services in production. Deploys 100 times per day. Uber Has 1,000+ services in production. Deploys several thousand times each week. WeChat Has 3,000+ services in production. Deploys 1,000 times a day.
  • 19. 5 CHAPTER 1 | Introduction to cloud-native applications As you can see, Netflix, Uber, and, WeChat expose cloud-native systems that consist of many independent services. This architectural style enables them to rapidly respond to market conditions. They instantaneously update small areas of a live, complex application, without a full redeployment. They individually scale services as needed. The pillars of cloud native The speed and agility of cloud native derive from many factors. Foremost is cloud infrastructure. But there’s more: Five other foundational pillars shown in Figure 1-3 also provide the bedrock for cloud- native systems. Figure 1-3. Cloud-native foundational pillars Let’s take some time to better understand the significance of each pillar. The cloud Cloud-native systems take full advantage of the cloud service model. Designed to thrive in a dynamic, virtualized cloud environment, these systems make extensive use of Platform as a Service (PaaS) compute infrastructure and managed services. They treat the underlying infrastructure as disposable - provisioned in minutes and resized, scaled, or destroyed on demand – via automation. Consider the widely accepted DevOps concept of Pets vs. Cattle. In a traditional data center, servers are treated as Pets: a physical machine, given a meaningful name, and cared for. You scale by adding more resources to the same machine (scaling up). If the server becomes sick, you nurse it back to health. Should the server become unavailable, everyone notices. The Cattle service model is different. You provision each instance as a virtual machine or container. They’re identical and assigned a system identifier such as Service-01, Service-02, and so on. You scale by creating more of them (scaling out). When one becomes unavailable, nobody notices. The cattle model embraces immutable infrastructure. Servers aren’t repaired or modified. If one fails or requires updating, it’s destroyed and a new one is provisioned – all done via automation. Cloud-native systems embrace the Cattle service model. They continue to run as the infrastructure scales in or out with no regard to the machines upon which they’re running.
  • 20. 6 CHAPTER 1 | Introduction to cloud-native applications The Azure cloud platform supports this type of highly elastic infrastructure with automatic scaling, self-healing, and monitoring capabilities. Modern design How would you design a cloud-native app? What would your architecture look like? To what principles, patterns, and best practices would you adhere? What infrastructure and operational concerns would be important? The Twelve-Factor Application A widely accepted methodology for constructing cloud-based applications is the Twelve-Factor Application. It describes a set of principles and practices that developers follow to construct applications optimized for modern cloud environments. Special attention is given to portability across environments and declarative automation. While applicable to any web-based application, many practitioners consider Twelve-Factor a solid foundation for building cloud-native apps. Systems built upon these principles can deploy and scale rapidly and add features to react quickly to market changes. The following table highlights the Twelve-Factor methodology: Factor Explanation 1 - Code Base A single code base for each microservice, stored in its own repository. Tracked with version control, it can deploy to multiple environments (QA, Staging, Production). 2 - Dependencies Each microservice isolates and packages its own dependencies, embracing changes without impacting the entire system. 3 - Configurations Configuration information is moved out of the microservice and externalized through a configuration management tool outside of the code. The same deployment can propagate across environments with the correct configuration applied. 4 - Backing Services Ancillary resources (data stores, caches, message brokers) should be exposed via an addressable URL. Doing so decouples the resource from the application, enabling it to be interchangeable. 5 - Build, Release, Run Each release must enforce a strict separation across the build, release, and run stages. Each should be tagged with a unique ID and support the ability to roll back. Modern CI/CD systems help fulfill this principle. 6 - Processes Each microservice should execute in its own process, isolated from other running services. Externalize required state to a backing service such as a distributed cache or data store. 7 - Port Binding Each microservice should be self-contained with its interfaces and functionality exposed on its own port. Doing so provides isolation from other microservices.
  • 21. 7 CHAPTER 1 | Introduction to cloud-native applications Factor Explanation 8 - Concurrency When capacity needs to increase, scale out services horizontally across multiple identical processes (copies) as opposed to scaling-up a single large instance on the most powerful machine available. Develop the application to be concurrent making scaling out in cloud environments seamless. 9 - Disposability Service instances should be disposable. Favor fast startup to increase scalability opportunities and graceful shutdowns to leave the system in a correct state. Docker containers along with an orchestrator inherently satisfy this requirement. 10 - Dev/Prod Parity Keep environments across the application lifecycle as similar as possible, avoiding costly shortcuts. Here, the adoption of containers can greatly contribute by promoting the same execution environment. 11 - Logging Treat logs generated by microservices as event streams. Process them with an event aggregator. Propagate log data to data-mining/log management tools like Azure Monitor or Splunk and eventually to long-term archival. 12 - Admin Processes Run administrative/management tasks, such as data cleanup or computing analytics, as one-off processes. Use independent tools to invoke these tasks from the production environment, but separately from the application. In the book, Beyond the Twelve-Factor App, author Kevin Hoffman details each of the original 12 factors (written in 2011). Additionally, he discusses three extra factors that reflect today’s modern cloud application design. New Factor Explanation 13 - API First Make everything a service. Assume your code will be consumed by a front- end client, gateway, or another service. 14 - Telemetry On a workstation, you have deep visibility into your application and its behavior. In the cloud, you don’t. Make sure your design includes the collection of monitoring, domain-specific, and health/system data. 15 - Authentication/ Authorization Implement identity from the start. Consider RBAC (role-based access control) features available in public clouds. We’ll refer to many of the 12+ factors in this chapter and throughout the book. Azure Well-Architected Framework Designing and deploying cloud-based workloads can be challenging, especially when implementing cloud-native architecture. Microsoft provides industry standard best practices to help you and your team deliver robust cloud solutions. The Microsoft Well-Architected Framework provides a set of guiding tenets that can be used to improve the quality of a cloud-native workload. The framework consists of five pillars of architecture excellence:
  • 22. 8 CHAPTER 1 | Introduction to cloud-native applications Tenets Description Cost management Focus on generating incremental value early. Apply Build-Measure-Learn principles to accelerate time to market while avoiding capital-intensive solutions. Using a pay- as-you-go strategy, invest as you scale out, rather than delivering a large investment up front. Operational excellence Automate the environment and operations to increase speed and reduce human error. Roll problem updates back or forward quickly. Implement monitoring and diagnostics from the start. Performance efficiency Efficiently meet demands placed on your workloads. Favor horizontal scaling (scaling out) and design it into your systems. Continually conduct performance and load testing to identify potential bottlenecks. Reliability Build workloads that are both resilient and available. Resiliency enables workloads to recover from failures and continue functioning. Availability ensures users access to your workload at all times. Design applications to expect failures and recover from them. Security Implement security across the entire lifecycle of an application, from design and implementation to deployment and operations. Pay close attention to identity management, infrastructure access, application security, and data sovereignty and encryption. To get started, Microsoft provides a set of online assessments to help you assess your current cloud workloads against the five well-architected pillars. Microservices Cloud-native systems embrace microservices, a popular architectural style for constructing modern applications. Built as a distributed set of small, independent services that interact through a shared fabric, microservices share the following characteristics: • Each implements a specific business capability within a larger domain context. • Each is developed autonomously and can be deployed independently. • Each is self-contained encapsulating its own data storage technology, dependencies, and programming platform. • Each runs in its own process and communicates with others using standard communication protocols such as HTTP/HTTPS, gRPC, WebSockets, or AMQP. • They compose together to form an application. Figure 1-4 contrasts a monolithic application approach with a microservices approach. Note how the monolith is composed of a layered architecture, which executes in a single process. It typically consumes a relational database. The microservice approach, however, segregates functionality into independent services, each with its own logic, state, and data. Each microservice hosts its own datastore.
  • 23. 9 CHAPTER 1 | Introduction to cloud-native applications Figure 1-4. Monolithic versus microservices architecture Note how microservices promote the Processes principle from the Twelve-Factor Application, discussed earlier in the chapter. Factor #6 specifies “Each microservice should execute in its own process, isolated from other running services.” Why microservices? Microservices provide agility. Earlier in the chapter, we compared an eCommerce application built as a monolith to that with microservices. In the example, we saw some clear benefits: • Each microservice has an autonomous lifecycle and can evolve independently and deploy frequently. You don’t have to wait for a quarterly release to deploy a new features or update. You can update a small area of a live application with less risk of disrupting the entire system. The update can be made without a full redeployment of the application. • Each microservice can scale independently. Instead of scaling the entire application as a single unit, you scale out only those services that require more processing power to meet desired performance levels and service-level agreements. Fine-grained scaling provides for greater control of your system and helps reduce overall costs as you scale portions of your system, not everything. An excellent reference guide for understanding microservices is .NET Microservices: Architecture for Containerized .NET Applications. The book deep dives into microservices design and architecture. It’s a companion for a full-stack microservice reference architecture available as a free download from Microsoft. Developing microservices Microservices can be created upon any modern development platform.
  • 24. 10 CHAPTER 1 | Introduction to cloud-native applications The Microsoft .NET platform is an excellent choice. Free and open source, it has many built-in features that simplify microservice development. .NET is cross-platform. Applications can be built and run on Windows, macOS, and most flavors of Linux. .NET is highly performant and has scored well in comparison to Node.js and other competing platforms. Interestingly, TechEmpower conducted an extensive set of performance benchmarks across many web application platforms and frameworks. .NET scored in the top 10 - well above Node.js and other competing platforms. .NET is maintained by Microsoft and the .NET community on GitHub. Microservice challenges While distributed cloud-native microservices can provide immense agility and speed, they present many challenges: Communication How will front-end client applications communicate with backed-end core microservices? Will you allow direct communication? Or, might you abstract the back-end microservices with a gateway facade that provides flexibility, control, and security? How will back-end core microservices communicate with each other? Will you allow direct HTTP calls that can increase coupling and impact performance and agility? Or might you consider decoupled messaging with queue and topic technologies? Communication is covered in the Cloud-native communication patterns chapter. Resiliency A microservices architecture moves your system from in-process to out-of-process network communication. In a distributed architecture, what happens when Service B isn’t responding to a network call from Service A? Or, what happens when Service C becomes temporarily unavailable and other services calling it become blocked? Resiliency is covered in the Cloud-native resiliency chapter. Distributed Data By design, each microservice encapsulates its own data, exposing operations via its public interface. If so, how do you query data or implement a transaction across multiple services? Distributed data is covered in the Cloud-native data patterns chapter. Secrets How will your microservices securely store and manage secrets and sensitive configuration data? Secrets are covered in detail Cloud-native security.
  • 25. Random documents with unrelated content Scribd suggests to you:
  • 26. Meru,” say the texts. Meru was its Amnion, and the other mountains were its Chorion, adds a verse in Vishnu Purâna.768 In the same way is man born in his mother's womb. As Brahmâ is surrounded, in exoteric traditions, by seven layers within and seven without the Mundane Egg, so is the embryo (the first or the seventh layer, according to the end from which we begin to count). Thus, just as Esotericism in its Cosmogony enumerates seven inner and seven outer layers, so Physiology notes the contents of the uterus as seven also, although it is completely ignorant of this being a copy of what takes place in the Universal Matrix. These contents are: 1. Embryo. 2. Amniotic Fluid, immediately surrounding the Embryo. 3. Amnion, a membrane derived from the Fœtus, which contains the fluid. 4. Umbilical Vesicle, which serves to convey nourishment originally [pg 441] to the Embryo and to nourish it. 5. Allantois, a protrusion from the Embryo in the form of a closed bag, which spreads itself between 3 and 7, in the midst of 6, and which, after being specialized into the Placenta, serves to conduct nourishment to the Embryo. 6. Interspace between 3 and 7 (the Amnion and Chorion), filled with an albuminous fluid. 7. Chorion, or outer layer. Now, each of these seven contents severally corresponds with, and is formed after, an antetype, one on each of the seven planes of being, with which in their turn correspond the seven states of Matter and all other forces, sensational or functional, in Nature. The following is a bird's-eye view of the seven correspondential contents of the wombs of Nature and of Woman. We may contrast them thus: (1) Cosmic Process: The mathematical Point, called the “Cosmic Seed,” the Monad of Leibnitz; which contains the whole Universe, as the acorn the oak. This is the first bubble on the surface of boundless homogeneous Substance, or Space, the bubble of
  • 27. differentiation in its incipient stage. It is the beginning of the Orphic or Brahmâ's Egg. It corresponds in Astrology and Astronomy to the Sun. Human Process: The terrestrial Embryo, which contains in it the future man with all his potentialities. In the series of principles of the human system it is the Âtman, or the super-spiritual principle, just as in the physical Solar System it is the Sun. (2) Cosmic Process: The vis vitæ of our solar system exudes from the Sun. Human Process: The Amniotic Fluid exudes from the Embryo. (a) Cosmic Process: It is called, when referred to the higher planes, Âkâsha. Human Process: It is called, on the plane of matter, Prâna.769 (b) Cosmic Process: It proceeds from the ten “divinities,” the ten numbers of the Sun, which is itself the “Perfect Number.” These are called Dis—in reality Space—the forces spread in Space, three of which are contained in the Sun's Âtman, or seventh principle, and seven are the rays shot out by the Sun. Human Process: It proceeds, taking its source in the universal One Life, from the heart of man and Buddhi, over which the Seven Solar Rays (Gods) preside. [pg 442] (3) Cosmic Process: The Ether of Space, which, in its external aspect, is the plastic crust which is supposed to envelope the Sun. On the higher plane it is the whole Universe, as the third differentiation of evolving Substance, Mûlaprakriti becoming Prakriti. Human Process: The Amnion, the membrane containing the Amniotic Fluid and enveloping the Embryo. After the birth of man it becomes the third layer, so to say, of his magneto-vital aura. (a) Cosmic Process: It corresponds mystically to the manifested Mahat, or the Intellect or Soul of the World. Human Process: Manas, the third principle (counting from above), or the Human Soul in Man.
  • 28. (4) Cosmic Process: The sidereal contents of Ether, the substantial parts of it, unknown to Modern Science, represented as follows. Human Process: Umbilical Vesicle, serving, as Science teaches, to nourish the Embryo originally, but, as Occult Science avers, to carry to the Fœtus by osmosis the cosmic influences extraneous to the mother. (a) Cosmic Process: In Occult and Kabalistic Mysteries, by Elementals. Human Process: In the grown man these become the feeders of Kâma, over which they preside. (b) Cosmic Process: In physical Astronomy, by meteors, comets, and all kinds of casual and phenomenal cosmic bodies. Human Process: In the physical man, his passions and emotions, the moral meteors and comets of human nature. (5) Cosmic Process: Life currents in Ether, having their origin in the Sun: the canals through which the vital principle of that Ether (the blood of the Cosmic Body) passes to nourish everything on the Earth and on the other Planets: from the minerals, which are thus made to grow and become specialized, from the plants, which are thus fed, to animal and man, to whom life is thus imparted. Human Process: The Allantois, a protrusion from the Embryo, which spreads itself between the Amnion and Chorion; it is supposed to conduct the nourishment from the mother to the Embryo. It corresponds to the life-principle, Prâna or Jîva. [pg 443] (6) Cosmic Process: The double radiation, psychic and physical, which radiates from the Cosmic Seed and expands around the whole Kosmos, as well as around the Solar System and every Planet. In Occultism it is called the upper divine, and the lower material, Astral Light. Human Process: The Allantois is divided into two layers. The interspace between the Amnion and the Chorion contains the Allantois and also an albuminous fluid.770
  • 29. (7) Cosmic Process: The outer crust of every sidereal body, the Shell of the Mundane Egg, or the sphere of our Solar System, of our Earth, and of every man and animal. In sidereal space, Ether proper; on the terrestrial plane, Air, which again is built in seven layers. Human Process: The Chorion, or the Zona Pellucida, the globular object called Blastodermic Vesicle, the outer and the inner layers of the membrane of which go to form the physical man. The outer, or ectoderm, forms his epidermis; the inner, or endoderm, his muscles, bones, etc. Man's skin, again, is composed of seven layers. (a) Cosmic Process: The primordial potential world-stuff becomes (for the Manvantaric period) the permanent globe or globes. Human Process: The “primitive” becomes the “permanent” Chorion. Even in the evolution of the Races we see the same order as in Nature and Man.771 Placental animal-man became such only after the separation of sexes in the Third Root-Race. In the physiological evolution, the placenta is fully formed and functional only after the third month of uterine life. [pg 444] Let us put aside such human conceptions as a personal God, and hold to the purely divine, to that which underlies all and everything in boundless Nature. It is called by its Sanskrit Esoteric name in the Vedas, Tat (or That), a term for the unknowable Rootless Root. If we do so, we may answer these seven questions of the Esoteric Catechism thus: (1) Q.—What is the Eternal Absolute? A.—That. (2) Q.—How came Kosmos into being? A.—Through That. (3) Q.—How, or what will it be when it falls back into Pralaya? A.—In That.
  • 30. (4) Q.—Whence all the animate, and suppositionally, the “inanimate”nature? A.—From That. (5) Q.—What is the Substance and Essence of which the Universe is formed? A.—That. (6) Q.—Into what has it been and will be again and again resolved? A.—Into That. (7) Q.—Is That then both the instrumental and material cause of the Universe? A.—What else is it or can it be than That? As the Universe, the Macrocosm and the Microcosm,772 are ten, why should we divide Man into seven “principles”? This is the reason why the perfect number ten is divided into two: in their completeness, i.e., super- spiritually and physically, the forces are ten: to wit, three on the subjective and inconceivable, and seven on the objective plane. Bear in mind that I am now giving you the description of the two opposite poles: (a) the primordial Triangle, which, as soon as it has reflected itself in the “Heavenly Man,” the highest of the lower seven—disappears, returning into “Silence and Darkness”; and (b) the astral paradigmatic man, whose Monad (Âtmâ) is also represented by a triangle, as it has to become a ternary in conscious Devachanic interludes. The purely terrestrial man being reflected in the universe of Matter, so to say, upside down, the upper Triangle, wherein the creative ideation and the subjective potentiality of the formative faculty resides, [pg 445] is shifted in the man of clay below the seven. Thus three of the ten, containing in the archetypal world only ideative and paradigmatical potentiality, i.e., existing in possibility, not in action, are in fact one. The potency of formative creation resides in the Logos, the synthesis of the seven Forces or Rays, which becomes forthwith the Quaternary, the sacred Tetraktys. This process is repeated in man, in whom the lower physical triangle
  • 31. becomes, in conjunction with the female One, the male-female creator, or generator. The same on a still lower plane in the animal world. A mystery above, a mystery below, truly. This is how the upper and highest, and the lower and most animal, stand in mutual relation. Diagram I 1st—Macrocosm and Its 3, 7, or 10 Centres of Creative Forces A. B. C. The Unknowable A. Sexless, Unmanifested Logos B. Potential Wisdom C. Universal Ideation
  • 32. a. Creative Logos b. Eternal Substance c. Spirit a. b. c. This is Pradhâna, undifferentiated matter in Sânkhya philosophy, or Good, Evil and Chaotic Darkness (Sattva, Rajas, and Tamas), neutralizing each other. When differentiated, they become the Seven Creative Potencies: Spirit, Substance and Fire stimulating Matter to form itself. D. The Spiritual Forces acting in Matter 2nd.—Microcosm (the Inner Man) and his 3, 7, or 10 Centres of Potential Forces (ÂTMAN, although exoterically reckoned as the seventh principle, is no individual principle at all, and belongs to the Universal Soul; 7 is the AURIC EGG, the Magnetic Sphere round every human and animal being.) 1. Buddhi, the vehicle of Âtmâ. 2. Manas, the vehicle of Buddhi.
  • 33. 3. Lower Manas (the Upper and Lower Manas are two aspects of one and the same principle) and 4. Kâma Rûpa, its vehicle. 5. Prâna, Life, and 6. Linga Sharira, its vehicle I. II. III. are the Three Hypostases of Âtman, its contact with Nature and Man being the Fourth, making it a Quaternary, or Tetraktys, the Higher self. 1. 2. 3. 4. 5. 6. These six principles, acting on four different planes, and having their Auric Envelope on the seventh (vide infra), are those used by the Adepts of the Right-Hand, or White Magicians. 3rd.—Microcosm (the Physical Man) and his 10 Orifices, or centres of Action 1. (Buddhi) Right Eye 3. (Lower Manas) Right Ear
  • 34. 5. (Life Principle) Right Nostril 7. The Organ of the Creative Logos, the Mouth 8. 9. 10. As this Lower Ternary has a direct connection with the Higher Âtmic Triad and its three aspects (creative, preservative and destructive, or rather regenerative), the abuse of the corresponding functions is the most terrible of Karmic Sins—the Sin against the Holy Ghost with the Christians. 2. (Manas) Left Eye 4. (Kâma Rûpa) Left Ear 6. (Life Vehicle) Left Nostril 7. The Paradigm of the 10th (creative) orifice in the Lower Triad. These Physical Organs are used only by Dugpas in Black Magic. In this diagram, we see that physical man (or his body) does not share in the direct pure waves of the divine Essence which flows from the One in Three, the Unmanifested, through the Manifested Logos (the upper face in the diagram). Purusha, the primeval Spirit, touches the human head and stops there. But the Spiritual Man (the synthesis of the seven principles) is directly connected with it. And here a few words ought to be said about the usual exoteric enumeration of the principles. At first an approximate division only was made and given out. Esoteric Buddhism begins with Âtmâ, the seventh, and ends with the Physical Body, the first. Now neither Âtmâ, which is no individual “principle,” but a radiation from and one with the Unmanifested Logos; nor the Body, which is the material rind, or shell, of the Spiritual Man, can be, in strict truth, referred to as “principles.” Moreover, the chief “principle” of all, one not even mentioned heretofore, is the “Luminous Egg” (Hiranyagarbha), or the invisible magnetic sphere in which every man is enveloped.773 It is the direct emanation: (a) from the Âtmic Ray in its triple aspect of Creator, Preserver and Destroyer (Regenerator); and (b) from Buddhi-Manas. The seventh aspect of this individual Aura is the faculty of assuming the form of its body and becoming the “Radiant,” the Luminous Augoeides. It is
  • 35. this, strictly speaking, which at times becomes the form called Mâyâvi Rûpa. Therefore, as explained in the second face of the diagram (the astral man), the Spiritual Man consists of only five [pg 446] principles, as taught by the Vedântins,774 who substitute, tacitly, for the physical this sixth, or Auric, Body, and merge the dual Manas (the dual mind, or consciousness) into one. Thus they speak of five Koshas (sheaths or principles), and call Âtmâ the sixth yet no “principle.” This is the secret of the late Subba Row's criticism of the division in Esoteric Buddhism. But let the student now learn the true Esoteric enumeration. The reason why public mention of the Auric Body was not permitted was on account of its being so sacred. It is this Body which, at death, assimilates the essence of Buddhi and Manas and becomes the vehicle of these spiritual principles, which are not objective, and then, with the full radiation of Âtmâ upon it ascends as Manas-Taijasi into the Devachanic state. Therefore is it called by many names. It is the Sûtrâtmâ, the silver “thread” which “incarnates” from the beginning of Manvantara to the end, stringing upon itself the pearls of human existence, in other words, the spiritual aroma of every personality it follows through the pilgrimage of life.775 It is also the material from which the Adept forms his Astral Bodies, from the Augoeides and the Mâyâvi Rûpa downwards. After the death of man, when its most ethereal particles have drawn into themselves the spiritual principles of Buddhi and the Upper Manas, and are illuminated with the radiance of Âtmâ, the Auric Body remains either in the Devachanic state of consciousness, or, in the case of a full Adept, prefers the state of a Nirmânakâya, that is, one who has so purified his whole system that he is above even the divine illusion of a Devachanî. Such an Adept remains in the astral (invisible) plane connected with our earth, and henceforth moves and lives in the possession of all his principles except the Kâma Rûpa and Physical Body. In the case of the Devachanî, the Linga Sharîra—the alter ego of the body, which during life is within the physical envelope while the radiant aura is without—strengthened by the material particles which this aura leaves behind, remains close to the dead body and outside it, and soon fades away. In the case of the full Adept, the body alone becomes subject to dissolution, while the centre of that force which was the seat of desires and passions, disappears with its cause—the animal body. But during the life of the latter all these centres are more or less active and in constant correspondence [pg 447] with
  • 36. their prototypes, the cosmic centres, and their microcosms, the principles. It is only through these cosmic and spiritual centres that the physical centres (the upper seven orifices and the lower triad) can benefit by their Occult interaction, for these orifices, or openings, are channels conducting into the body the influences that the will of man attracts and uses, viz., the cosmic forces. This will has, of course, to act primarily through the spiritual principles. To make this clearer, let us take an example. In order to stop pain, let us say in the right eye, you have to attract to it the potent magnetism from that cosmic principle which corresponds to this eye and also to Buddhi. Create, by a powerful will effort, an imaginary line of communication between the right eye and Buddhi, locating the latter as a centre in the same part of the head. This line, though you may call it “imaginary,” is, once you succeed in seeing it with your mental eye and give it a shape and colour, in truth as good as real. A rope in a dream is not and yet is. Moreover, according to the prismatic colour with which you endow your line, so will the influence act. Now Buddhi and Mercury correspond with each other, and both are yellow, or radiant and golden coloured. In the human system, the right eye corresponds with Buddhi and Mercury; and the left with Manas and Venus or Lucifer. Thus, if your line is golden or silvery, it will stop the pain; if red, it will increase it, for red is the colour of Kâma and corresponds with Mars. Mental or Christian Scientists have stumbled upon the effects without understanding the causes. Having found by chance the secret of producing such results owing to mental abstraction, they attribute them to their union with God (whether a personal or impersonal God they know best), whereas it is simply the effect of one or another principle. However it may be, they are on the path of discovery, although they must remain wandering for a long time to come. Let not Esoteric students commit the same mistake. It has often been explained that neither the cosmic planes of substance nor even the human principles—with the exception of the lowest material plane or world and the physical body, which, as has been said, are no “principles,”—can be located or thought of as being in Space and Time. As the former are seven in One, so are we seven in One—that same absolute Soul of the World, which is both Matter and non-Matter, Spirit and non-
  • 37. Spirit, Being and non-Being. Impress yourselves well with this idea, all those of you who would study the mysteries of Self. Remember that with our physical senses alone at our command, none [pg 448] of us can hope to reach beyond gross Matter. We can do so only through one or another of our seven spiritual senses, either by training, or if one is a born Seer. Yet even a clairvoyant possessed of such faculties, if not an Adept, no matter how honest and sincere he may be, will, through his ignorance of the truths of Occult Science, be led by the visions he sees in the Astral Light only to mistake for God or Angels the denizens of those spheres of which he may occasionally catch a glimpse, as witness Swedenborg and others. These seven senses of ours correspond with every other septenate in nature and in ourselves. Physically, though invisibly, the human Auric Envelope (the amnion of the physical man in every age of life) has seven layers, just as Cosmic Space and our physical epidermis have. It is this Aura which, according to our mental and physical state of purity or impurity, either opens for us vistas into other worlds, or shuts us out altogether from anything but this three-dimensional world of Matter. Each of our seven physical senses (two of which are still unknown to profane Science), and also of our seven states of consciousness—viz.: (1) waking; (2) waking-dreaming; (3) natural sleeping; (4) induced or trance- sleep; (5) psychic; (6) super-psychic; and (7) purely spiritual— corresponds with one of the seven Cosmic Planes, develops and uses one of the seven super-senses, and is connected directly, in its use on the terrestro-spiritual plane, with the cosmic and divine centre of force that gave it birth, and which is its direct creator. Each is also connected with, and under the direct influence of, one of the seven sacred Planets.776 These belonged to the Lesser Mysteries, whose followers were called Mystai (the veiled), seeing that they were allowed to perceive things only through a mist, as it were “with the eyes closed”; while the Initiates or “Seers” of the Greater Mysteries were called Epoptai (those who see things unveiled). It was the latter only who were taught the true mysteries of the Zodiac and the relations and correspondences between its twelve signs (two secret) and the ten human orifices. The latter are now of course ten in the female, and only nine in the male; but this is merely an external difference. In the second volume of this work it is
  • 38. stated that till the end of the Third Root-Race (when androgynous man separated into male and female) the ten orifices existed in the hermaphrodite, first potentially, then [pg 449] functionally. The evolution of the human embryo shows this. For instance, the only opening formed at first is the buccal cavity, “a cloaca communicating with the anterior extremity of the intestine.” These become later the mouth and the posterior orifice: the Logos differentiating and emanating gross matter on the lower plane, in Occult parlance. The difficulty which some students will experience in reconciling the correspondences between the Zodiac and the orifices can be easily explained. Magic is coëval with the Third Root-Race, which began by creating through Kriyâshakti and ended by generating its species in the present way.777 Woman, being left with the full or perfect cosmic number 10 (the divine number of Jehovah), was deemed higher and more spiritual than man. In Egypt, in days of old, the marriage service contained an article that the woman should be the “lady of the lord,” and real lord over him, the husband pledging himself to be “obedient to his wife” for the production of alchemical results such as the Elixir of Life and the Philosopher's Stone, for the spiritual help of the woman was needed by the male Alchemist. But woe to the Alchemist who should take this in the dead-letter sense of physical union. Such sacrilege would become Black Magic and be followed by certain failure. The true Alchemist of old took aged women to help him, carefully avoiding the young ones; and if any of them happened to be married they treated their wives for months both before and during their operations as sisters. The error of crediting the Ancients with knowing only ten of the zodiacal signs is explained in Isis Unveiled.778 The Ancients did know of twelve, but viewed these signs differently from ourselves. They took neither Virgo nor Scorpio singly into consideration, but regarded them as two in one, since they were made to refer directly and symbolically to the primeval dual man and his separation into sexes. During the reformation of the Zodiac, Libra was added as the twelfth sign, though it is simply an equilibrating sign, at the turning point—the mystery of separated man. Let the student learn all this well. Meanwhile we have to recapitulate what has been said. (1) Each human being is an incarnation of his God, in other words, one with his “Father in Heaven,” just as Jesus, an Initiate, is made to say. As
  • 39. many men on earth, so many Gods in Heaven; and yet these [pg 450] Gods are in reality One, for at the end of every period of activity, they are withdrawn, like the rays of the setting sun, into the Parent Luminary, the Non-Manifested Logos, which in its turn is merged into the One Absolute. Shall we call these “Fathers” of ours, whether individually or collectively, and under any circumstances, our personal God? Occultism answers, Never. All that an average man can know of his “Father” is what he knows of himself, through and within himself. The Soul of his “Heavenly Father” is incarnated in him. This Soul is himself, if he be successful in assimilating the Divine Individuality while in his physical, animal shell. As to the Spirit thereof, as well expect to be heard by the Absolute. Our prayers and supplications are vain, unless to potential words we add potent acts, and make the Aura which surrounds each one of us so pure and divine that the God within us may act outwardly, or in other words, become as it were an extraneous Potency. Thus have Initiates, Saints, and very holy and pure men been enabled to help others as well as themselves in the hour of need, and produce what are foolishly called “miracles,” each by the help and with the aid of the God within himself, which he alone has enabled to act on the outward plane. (2) The word Aum or Om, which corresponds to the upper Triangle, if pronounced by a very holy and pure man, will draw out, or awaken, not only the less exalted Potencies residing in the planetary spaces and elements, but even his Higher Self, or the “Father” within him. Pronounced by an averagely good man, in the correct way, it will help to strengthen him morally, especially if between two “Aums” he meditates intently upon the Aum within him, concentrating all his attention upon the ineffable glory. But woe to the man who pronounces it after the commission of some far-reaching sin: he will only thereby attract to his own impure photosphere invisible Presences and Forces which could not otherwise break through the Divine Envelope. Aum is the original of Amen. Now, Amen is not a Hebrew term, but, like the word Halleluiah, was borrowed by the Jews and Greeks from the Chaldees. The latter word is often found repeated in certain magical inscriptions upon cups and urns among the Babylonian and Ninevean relics. Amen does not mean “so be it,” or “verily,” but signified in hoary antiquity almost the same as Aum. The Jewish Tanaïm (Initiates) used it
  • 40. for the same reason as the Âryan Adepts use Aum, and with a like success, the numerical value of AMeN in Hebrew [pg 451] letters being 91, the same as the full value of YHVH,779 26, and ADoNaY, 65, or 91. Both words mean the affirmation of the being, or existence, of the sexless “Lord” within us. (3) Esoteric Science teaches that every sound in the visible world awakens its corresponding sound in the invisible realms, and arouses to action some force or other on the Occult side of Nature. Moreover, every sound corresponds to a colour and a number (a potency spiritual, psychic or physical) and to a sensation on some plane. All these find an echo in every one of the so-far developed elements, and even on the terrestrial plane, in the Lives that swarm in the terrene atmosphere, thus prompting them to action. Thus a prayer, unless pronounced mentally and addressed to one's “Father” in the silence and solitude of one's “closet,” must have more frequently disastrous than beneficial results, seeing that the masses are entirely ignorant of the potent effects which they thus produce. To produce good effects, the prayer must be uttered by “one who knows how to make himself heard in silence,” when it is no longer a prayer, but becomes a command. Why is Jesus shown to have forbidden his hearers to go to the public synagogues? Surely every praying man was not a hypocrite and a liar, nor a Pharisee who loved to be seen praying by people! He had a motive, we must suppose: the same motive which prompts the experienced Occultist to prevent his pupils from going into crowded places now as then, from entering churches, séance rooms, etc., unless they are in sympathy with the crowd. There is one piece of advice to be given to beginners, who cannot help going into crowds—one which may appear superstitious, but which in the absence of Occult knowledge will be found efficacious. As well known to good Astrologers, the days of the week are not in the order of those planets whose names they bear. The fact is that the ancient Hindus and Egyptians divided the day into four parts, each day being under the protection (as ascertained by practical magic) of a planet; and every day, as correctly asserted by Dion Cassius, received the name of the planet which ruled and protected its first portion. Let the student protect himself from the “Powers of the Air” (Elementals) which throng public places, by
  • 41. wearing either a ring containing some jewel of the colour of the presiding planet, or else of the metal sacred to it. But the best protection is a clear conscience and a firm desire to benefit Humanity. [pg 452] The Planets, The Days of the Week and Their Corresponding Colours and Metals. [Transcriber's Note: This table was a wide pull-out insert into the book, with more columns than modern readers can display. It has been reformatted into several tables of more manageable width.] These Correspondences are from the Objective, Terrestrial Plane. Âtman is no Number, and corresponds to no visible Planet, for it proceeds from the Spiritual Sun; nor does it bear any relation either to Sound, Colour, or the rest, for it includes them all. As the Human Principles have no Numbers per se, but only correspond to Numbers, Sounds, Colours, etc., they are not enumerated here in the order used for exoteric purposes. NUMBERS METALS. PLANETS. 1 and 10. Physical Man's Key-note. Iron. Mars. The Planet of Generation. 2. Life Spiritual and Life Physical. Gold. The Sun. The Giver of Life physically. Spiritually and esoterically the substitute for the inter-Mercurial Planet, a sacred and secret planet with the ancients.
  • 42. 3. Because Buddhi is (so to speak) between Âtmâ and Manas, and forms with the seventh, or Auric Envelope, the Devachanic Triad. Mercury. Mixes with Sulphur, as Buddhi is mixed with the Flame of Spirit (See Alchemical Definitions.) Mercury. The Messenger and the Interpreter of the Gods. 4. The middle principle—between the purely material and purely spiritual triads. The conscious part of animal man. Lead. Saturn. 5. Tin. Jupiter. 6. Copper. When alloyed becomes Bronze (the dual principle). Venus. The Morning and the Evening Star. 7. Contains in itself the reflection of Septenary Man. Silver. The Moon. The Patent of the Earth. NUMBERS THE HUMAN PRINCIPLES. DAYS OF THE WEEK. 1 and 10. Kâma Rûpa. The vehicle or seat of the Animal Instincts and Passions. Tuesday. Dies Martis, or Tiw. 2. Prâna or Jîva. Life. Sunday. Dies Solss, or Sun. 3. Buddhi. Spiritual Soul, or Âtmic Ray; vehicle of Âtmâ. Wednesday. Dies Mercurii, or Woden. Day of Buddha in the South, end of Woden in the North—Gods of Wisdom. 4. Kâma Manas. The Lower Mind, or Animal Soul. Saturday. Dies Saturns, or Saturn.
  • 43. 5. Auric Envelope. Thursday. Dies Jovis, or Thor. 6. Manas. The Higher Mind, or Human Soul. Friday. Dies Veneris, or Friga. 7. Linga Sharîra. The Astral Double of Man, the Parent of the Physical Man. NUMBERS COLOURS. SOUND. Musical Scale.. 1 and 10. 1 Red. Sa or Do. 2. 2 Orange. Ri or Re. 3. 3. Yellow. Ga or Mi. 4. 4. Green. Ma or Fa. 5. 5. Blue. Pa or Sol. 6. 6. Indigo or Dark Blue. Da or La. 7. 7. Violet. Ni or Si. In the accompanying diagram the days of the week do not stand in their usual order, though they are placed in their correct sequence as determined by the order of the colours in the solar spectrum and the corresponding colours of their ruling planets. The fault of the confusion in the order of the days revealed by this comparison lies at the door of the early Christians. Adopting from the Jews their lunar months, they tried to blend them with the solar planets, and so made a mess of it; for the order of the days of the week as it now stands does not follow the order of the planets. Now, the Ancients arranged the planets in the following order: Moon, Mercury, Venus, Sun, Mars, Jupiter, Saturn, counting the Sun as a planet for exoteric purposes. Again, the Egyptians and Indians, the two oldest nations, divided their day into four parts, each of which was under the protection and rule of a planet. In course of time each day came to be called by the name of that planet which ruled its first portion—the morning. Now, when they arranged their week, the Christians proceeded as follows: they wanted to make the day of the Sun, or Sunday, the seventh, so they named the days of the week by taking every fourth planet in turn; e.g., beginning with the Moon (Monday), they counted thus: Moon, Mercury, Venus, Sun, Mars; thus Tuesday, the day whose first
  • 44. portion was ruled by Mars, became the second day of the week; and so on. It should be remembered also that the Moon, like the Sun, is a substitute for a secret planet. The present division of the solar year was made several centuries later than the beginning of our era; and our week is not that of the Ancients and the Occultists. The septenary division of the four parts of the lunar phases is as old as the world, and originated with the people who reckoned time by the lunar months. The Hebrews never used it, for they counted only the seventh day, the Sabbath, though the second chapter of Genesis seems to speak of it. Till the days of the Cæsars there is no trace of a week of seven days among any nation save the Hindus. From India it passed to the Arabs, and reached Europe with Christianity. The Roman week consisted of eight days, and the Athenian of ten.780 Thus one of the numberless contradictions [pg 453] and fallacies of Christendom is the adoption of the Indian septenary week of the lunar reckoning, and the preservation at the same time of the mythological names of the planets. Nor do modern Astrologers give the correspondences of the days and planets and their colours correctly; and while Occultists can give good reason for every detail of their own tables of colours, etc., it is doubtful whether the Astrologers can do the same. To close this first Paper, let me say that the readers must in all necessity be separated into two broad divisions: those who have not quite rid themselves of the usual sceptical doubts, but who long to ascertain how much truth there may be in the claims of the Occultists; and those others who, having freed themselves from the trammels of Materialism and Relativity, feel that true and real bliss must be sought only in the knowledge and personal experience of that which the Hindu Philosopher calls the Brahmavidyâ, and the Buddhist Arhat the realization of Âdibuddha, the primeval Wisdom. Let the former pick out and study from these Papers only those explanations of the phenomena of life which profane Science is unable to give them. Even with such limitations, they will find by the end of a year or two that they will have learned more than all their Universities and Colleges can teach them. As to the sincere
  • 45. believers, they will be rewarded by seeing their faith transformed into knowledge. True knowledge is of Spirit and in Spirit alone, and cannot be acquired in any other way except through the region of the higher mind, the only plane from which we can penetrate the depths of the all- pervading Absoluteness. He who carries out only those laws established by human minds, who lives that life which is prescribed by the code of mortals and their fallible legislation, chooses as his guiding star a beacon which shines on the ocean of Mâyâ, or of temporary delusions, and lasts for but one incarnation. These laws are necessary for the life and welfare of physical man alone. He has chosen a pilot who directs him through the shoals of one existence, a master who parts with him, however, on the threshold of death. How much happier that man who, while strictly performing on the temporary objective plane the duties of daily life, carrying out each and every law of his country, and rendering, in short, to Cæsar what is Cæsar's, leads in reality a spiritual and permanent existence, a life with no breaks of continuity, no gaps, no interludes, [pg 454] not even during those periods which are the halting-places of the long pilgrimage of purely spiritual life. All the phenomena of the lower human mind disappear like the curtain of a proscenium, allowing him to live in the region beyond it, the plane of the noumenal, the one reality. If man by suppressing, if not destroying, his selfishness and personality, only succeeds in knowing himself as he is behind the veil of physical Mâyâ, he will soon stand beyond all pain, all misery, and beyond all the wear and tear of change, which is the chief originator of pain. Such a man will be physically of Matter, he will move surrounded by Matter, and yet he will live beyond and outside it. His body will be subject to change, but he himself will be entirely without it, and will experience everlasting life even while in temporary bodies of short duration. All this may be achieved by the development of unselfish universal love of Humanity, and the suppression of personality, or selfishness, which is the cause of all sin, and consequently of all human sorrow. [pg 455]
  • 47. Paper II. An Explanation. In view of the abstruse nature of the subjects dealt with, the present Paper will begin with an explanation of some points which remained obscure in the preceding one, as well as of some statements in which there was an appearance of contradiction. Astrologers, of whom there are many among the Esotericists, are likely to be puzzled by some statements distinctly contradicting their teachings; whilst those who know nothing of the subject may perhaps find themselves opposed at the outset by those who have studied the exoteric systems of the Kabalah and Astrology. For let it be distinctly known, nothing of that which is printed broadcast, and available to every student in public libraries or museums, is really Esoteric, but is either mixed with deliberate “blinds,” or cannot be understood and studied with profit without a complete glossary of Occult terms. The following teachings and explanations, therefore, may be useful to the student in assisting him to formulate the teaching given in the preceding Paper. In Diagram I. it will be observed that the 3, 7, and 10 centres are respectively as follows: (a) The 3 pertain to the spiritual world of the Absolute, and therefore to the three higher principles in Man. (b) The 7 belong to the spiritual, psychic, and physical worlds and to the body of man. Physics, metaphysics and hyper-physics are the triad that symbolizes man on this plane. (c) The 10, or the sum total of these, is the Universe as a whole, in all its aspects, and also its Microcosm—Man, with his ten orifices.
  • 48. Laying aside, for the moment, the Higher Decad (Kosmos) and the [pg 456] Lower Decad (Man), the first three numbers of the separate sevens have a direct reference to the Spirit, Soul and Auric Envelope of the human being, as well as to the higher supersensual world. The lower four, or the four aspects, belong to Man also, as well as to the Universal Kosmos, the whole being synthesized by the Absolute. If these three discrete or distributive degrees of Being be conceived, according to the Symbology of all the Eastern Religions, as contained in one Ovum, or Egg, the name of that Egg will be Svabhâvat, or the All- Being on the manifested plane. This Universe has, in truth, neither centre nor periphery; but in the individual and finite mind of man it has such a definition, the natural consequence of the limitations of human thought. In Diagram II., as already stated therein, no notice need be taken of the numbers used in the left-hand column, as these refer only to the Hierarchies of the Colours and Sounds on the metaphysical plane, and are not the characteristic numbers of the human principles or of the planets. The human principles elude enumeration, because each man differs from every other, just as no two blades of grass on the whole earth are absolutely alike. Numbering is here a question of spiritual progress and the natural predominance of one principle over another. With one man it may be Buddhi that stands as number one; with another, if he be a bestial sensualist, the Lower Manas. With one the physical body, or perhaps Prâna, the life principle, will be on the first and highest plane, as would be the case in an extremely healthy man, full of vitality; with another it may come as the sixth or even seventh downward. Again, the colours and metals corresponding to the planets and human principles, as will be observed, are not those known exoterically to modern Astrologers and Western Occultists. Let us see whence the modern Astrologer got his notions about the correspondence of planets, metals and colours. And here we are reminded of the modern Orientalist, who, judging by appearances credits the ancient Akkadians (and also the Chaldæans, Hindus and Egyptians) with the crude notion that the Universe, and in like manner the earth, was like an inverted, bell-shaped bowl! This he demonstrates by pointing to the symbolical representations of some Akkadian inscriptions and to the Assyrian carvings. It is, however, no place here to explain how
  • 49. mistaken is the Assyriologist, for all such representations are simply symbolical of the Khargakkurra, the World-Mountain, or Meru, and relate only to the North Pole, the Land of the [pg 457] Gods. Now, the Assyrians arranged their exoteric teaching about the planets and their correspondences as follows: Diagram II. Numbers. Planets. Metals. Colours. Solar Days of Week. 1. Saturn. Lead. Black. Saturday. (Whence Sabbath,781 in honour of Jehovah.) 2. Jupiter. Tin. White, but as often Purple or Orange. Thursday. 3. Mars. Iron. Red. Tuesday. 4. Sun. Gold. Yellow- golden. Sunday. 5. Venus. Copper. Green or Yellow. Friday. 6. Mercury. Quicksilver. Blue. Wednesday. 7. Moon. Silver. Silver- white. Monday. This is the arrangement now adopted by Christian Astrologers, with the exception of the order of the days of the week, of which, by associating the solar planetary names with the lunar weeks, they have made a sore mess, as has been already shown in Paper I. This is the Ptolemaic geocentric system, which represents the Universe as in the following diagram, showing our Earth in the centre of the Universe, and the Sun a Planet, the fourth in number. And if the Christian chronology and order of the days of the week are being daily denounced as being based on an entirely wrong astronomical
  • 50. foundation, it is high time to begin a reform also in Astrology built on such lines, and coming to us entirely from the Chaldæan and Assyrian exoteric mob. But the correspondences given in these Papers are purely Esoteric. [pg 458] For this reason it follows that when the Planets of the Solar System are named or symbolized (as in Diagram II.) it must not be supposed that the planetary bodies themselves are referred to, except as types on a purely physical plane of the septenary nature of the psychic and spiritual worlds. A material planet can correspond only to a material something. Thus when Mercury is said to correspond to the right eye, it does not mean that the objective planet has any influence on the right optic organ, but that both stand rather as corresponding mystically through Buddhi. Man derives his Spiritual Soul (Buddhi) from the essence of the Mânasa Putra, the Sons of Wisdom, who are the Divine Beings (or Angels) ruling and presiding over the planet Mercury. In the same way Venus, Manas and the left eye are set down as correspondences. Exoterically, there is, in reality, no such association of physical eyes and physical planets; but Esoterically there is; for the right eye is the “Eye of Wisdom,” i.e., it corresponds magnetically with that Occult centre in the brain which we call the “Third Eye”;782 while the left corresponds with the intellectual brain, or those cells which are the organ on the physical plane of the thinking faculty. The kabalistic triangle of Kether, Chokmah and Binah shows this. Chokmah and Binah, or Wisdom and Intelligence, the Father and Mother, or, again, the Father and Son, are on the same plane and reäct mutually on one another. When the individual consciousness is turned inward, a conjunction of Manas and Buddhi takes place. In the spiritually regenerated man this conjunction is permanent, the Higher Manas clinging to Buddhi beyond the threshold of Devachan, and the Soul, or rather the Spirit, which should not be confounded with Âtmâ, the Super-Spirit, is then said to have the “Single Eye.” Esoterically, in other words, the “Third Eye” is active. Now Mercury is called Hermes, and Venus, Aphrodite, and thus their conjunction in man on the psycho-physical plane gives him the name of the Hermaphrodite, or Androgyne. The absolutely Spiritual Man is, however, entirely disconnected from sex. The Spiritual Man corresponds directly with the higher “coloured circles,” the Divine Prism
  • 51. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com