Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor
Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor
Architecting Cloud Native Net Apps For Azure V103 V103 Robert Vettor
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
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
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.
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