3. Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
Middleware makes it easier for software developers to implement
communication and input/output, so they can focus on the specific purpose
of their application. It gained popularity in the 1980s as a solution to the
problem of how to link newer applications to older legacy systems, although
the term had been in use since 1968.[2]
Wikipedia!
Where is the middleware depicted in the picture?
4. Lets be more specific
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
5. Who offers middleware and can you avoid it?
Do it yourself (DIY) – App Service/IIS Logic Apps/Mulesoft/hundreds of
other vendors
Features
Send Mail Yes Yes
Connect to Symitar Yes Yes
Connect to Temenos Yes No
Many other features Always yes… Maybe….
Points to take home
• It is nearly impossible to avoid middleware in a line of business application. I had trouble even finding a ficticious
scenario where there would not be middleware…I imagined it would involved an Igloo and Antarctica.
• There is no silver bullet solution for all projects. Each of them have to evaluated individually and the right
architecture should be decided per project basis.
• Use guardrails (best practices to guide the architectural decision but don’t push a product).
• Middleware is a pipeline of how data is transmitted from point A to point B and is not a product
6. What is a Twelve-Factor App?
A 12-Factor app is a web app that follows the prescriptive
methodology conceived by the Heroku platform as a service (PaaS) for
cloud applications.
Benefits include:
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
Scalability Resiliency
Continuous
Delivery
Maintainability
Information
Security
7. + Pros
» Faster software delivery.
» Better security.
» Team unity and
understanding of each
other’s roles.
» Team works as a unit to
succeed and has
ownership of the overall
project success.
» Microservices do not
require teams to rewrite
the whole app if they
want to add new
features.
» Smaller codebases make
maintenance easier and
faster; saving a lot of
development effort and
time, thus increasing
overall productivity.
» Configuration drift is
reduced.
» The parts of an app can
be scaled separately and
are easier to deploy.
» Reduce outages –
uptime!
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
8. - Cons
» Very complicated –need to bring in experienced staff to handle the
complexity.
» Most invest heavily in monitoring tools, such as Dynatrace.
» Larger vector of attack – must invest in SIEM, CASB, PDP, and other
third party tools to maintain safety and data governance.
» Product owners must be willing to invest in their infrastructure and
long term speed to market.
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency Docker Conclusion
9. Summary of Impact
Business Unit Impact
PMO/ProductO
wners
As product owners, they will be able to have faster release cycles in the long
term, but the initial learning curve within teams will delay their deployments.
QA They will have to automate their tests because the impact could be
downstream. In addition, each version of the API has to have its own unique
test since you do not upgrade microservices, rather you simply deploy a new
one.
Infrastructure The will have to become part of the sprints.
Operations They will have to become part of the sprints for new project developments that
involve APIs or web apps.
Info Sec Their team has a larger vector of attack to cover.
Desktop
Support
Not affected.
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
10. Microservices – Difficult to Manage?
A 12-factor app inherently uses microservices. What are microservices
and are they something we can manage?
“Death Star” Architecture Diagrams
Netflix Gilt Groupe (12 of 450) Twitter
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
11. API Management
• Access to APIs will be controlled using
Azure AD authentication.
• API gateway serves as the linking point for
all services (internal + external).
• API management platform integrates with
our continuous integration infrastructure.
• Developer portal serves as a single point
of interaction across all developers to.
access/understand/develop/deploy APIs.
• Mulesoft serves as the API Development
and Orchestration Platform.
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
12. Internal - First App (Avoka),
(Salesforce)
Partners – Alkami.. Others!
Public - Member or any third party developed–
Rate Lookup, Branch Locations, Products
API
Execution
Business Friendly Micro-Services (REST)
Orchestration to Tie Multiple Micro-
Services
Exception Handling
Mapping to Downstream End Points
Security – Access, Authentication, Certification, Monitoring
Standards Conformation DocumentationDiscovery Monetization
API Monitoring
API
Management
Code Management
Jenkins
Backlog
Core/Block
Chain
Lending Mortgage Products Analytics ……..
Can be anywhere
On Prem, Cloud,
Hosted, etc.
Example Conceptual Architecture of API-Driven FI
External Services
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
13. Conceptual Microservices Architecture
SPA &
Mobile
App
Mobile
App
Backends for Frontends
Microservices for mobile
Microservices for SPA
RDB
Remote
Service
NoSQL
Strangler
API Gateway
GatewayRouting
&Aggregation
Microservice
Ambassad
or
Sidecar
Anti-corruption Layer
Legacy System RDB
Microservice
Ambassad
or
Sidecar
Microservice
Ambassad
or
Sidecar
Gateway
Offloading
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
14. Microservices Architecture Example
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
Mobile
App
AVOKA
API
Gateway
Firewall
CASB SIEM
Other APIs
Load Balanced
Core API Services
Ambassado
r
Azure Function/
Azure Event Grid
For MQ Processing
App Service
Logic App
Policy Decision
Point (PDP)
XACML
API FAÇADE Anti-Corruption Layer
Legacy Technology
(Jack Henry Symitar)
SPLUNK
Azure ASE
ILB
Ambassad
or
P2P
AZURE
ASE
ILB
Ambassador
Backend
for
Frontend
NoSQL/
SQL Server
WAF
15. Typical 3-Tier Architecture
Presentation Tier
The top-most level of the app is the UI. The main function of
the interface is to translate tasks and results to something
that the user can understand.
Logic Tier
This layer coordinates the app, processes commands, makes
logical decisions and evaluations, and performs calculations.
It also moves and processes data between the two
surrounding layers.
Data Tier
In this layer, information is stored and retrieved from a
database or file system. The information is then passed back
to the logic tier for processing, and then eventually back to
the user.
>GET SALES
TOTAL
>GET SALES
TOTAL
4 TOTAL
SALES
Get list of
all sales
made last
year
DatabaseStorage
Add all sales
together
Query
Sale 1
Sale 2
Sale 3
Sale 4
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
16. Hexagonal Architecture
Application
HTML5 App
Test Agent
REST
Adapter
SOAP
Adapter
TEST
Adapter
EI
Adapter
MQ
Adapter
SQL
Adapter
NoSQL
Adapter
Environme
nt
Adapter
ERP
CRM
DOC
s
File Source
Adapter
Enterprise Integration
Web Services
Database
Configuration
Messaging Queue
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
17. Example App Built for Speed
Application Services (Gateway/Edge Svc)
Read Model Microservice
UI Request (HTTP)
Redis
Commands & Queries
SQL Server
Domain Microservice
RabbitMQ
Commands Queries
Events Domain Events
Precomputed
Results
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
19. Solution
Developer
GitHub
Team City
Code Coverage
+ TDD
Git Push
GitHub Pull
Request Review
Pass Code
Review?
Merge Master/
Staging/QA/Dev
Yes
Azure DevOps
Build
No
Trigger
Prod
Environment
Staging
Environment
QA
Environment
Dev
Environment
Communicates
with
Pass
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
20. Dependencies
Requirement
A twelve-factor app that never relies on the implicit existence of system-wide packages. It
declares all dependencies, completely and exactly, via a dependency declaration manifest.
Solution
• NuGet Server + NPM
• NuGet Gallery is the central package repository used by all package authors and consumers.
• NPM is the package manager for JavaScript and the world’s largest software registry; it can be
used to discover packages of reusable code and assemble them in powerful new ways.
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
21. Present
» Copy NuGet packages to a
local share and have
everyone read off of that.
» We have a private
repository bldsrvr-
dev02NuGet
Repository for all our
NuGet packages. By
configuring the NuGet
Package Manager within VS
we gain access.
Alternative
» Obtain a license for myget and
store the nugget packages
there.
Dependencies: NuGet Server
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
22. Requirement
An app’s config is
everything that is likely
to vary between
deployment
environments (staging,
production, developer,
etc.)
Solution
» .NET projects use:
web.config
machine.config
project.json
(appsettings.jso
n)
Configuration
Anything that varies per environment:
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
23. Backing Services
» Resources can be attached and detached to deploys at
will.
» For example, if the app’s database is misbehaving due to
a hardware issue, the app’s administrator might spin up a
new database server restored from a recent backup.
» The current production database could be detached, and
the new database attached—all without any code
changes.
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
24. Concurrency
Applications sometimes need to run:
• Batch jobs
• Emails
• Workflows
• Other complex logic
A good UX would not wait for all the
services to be completed for the user
to continue interacting with the app.
What is
concurrency in the
context of a twelve
factor app?
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
25. Logic Apps
Logic Apps is a fully managed iPaaS (integration Platform as a Service) that handles hosting, scalability,
availability, and management—so developers don’t have to. It can scale up automatically to meet
demand.
Key features:
• Save time by designing complex processes using easy to understand design tools.
• Seamlessly implement patterns and workflows that would otherwise be difficult to implement
in code.
• Get started quickly from templates.
• Connectors to many cloud apps, such as Salesforce, FTP, SQL Server, SharePoint, etc.
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
26. Logic Apps /App Service
When a record is updated
Transform XML
Register in Datamart
If record requires action
Add to Service Bus topic
If Yes If No
Create a new record
Slack – Post Message
Execute stored procedure
Add an action Add an action
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
27. Disposability
Requirement
Deploying new code should not
affect production services
startup times.
Solution
App Service allows you to have the
right amount of resources running to
handle the load on an app. It allows
you to add resources to handle
increases in load and also save
money by removing resources that
are sitting idle.
Max = 5
VM VM
Min = 2
3 currently running
VM VM VM
+/- VMs as needed
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
28. Infrastructure
» Training
» Operations Tools
Azure Container
Registry
Security
Management
Monitoring and
logging
Developers
» Learn a
microservices
approach
» Learn .NET core
and avoid IIS
deployments
Training
» Continuous
» Frequent
» Bring experts on
site to teach and
evaluate practices
Change
Management
» Change in culture
» Change in team
structures
» Product owner has
to understand the
long term
investment and
that dev will slow
down at first.
Ok, I’m Sold – Let’s Begin Today…
First, let’s consider the following:
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
29. DevOps
Developers must work with Operations from the
start of the project and they have to be included
during the sprint planning as part of the ongoing
work to devise the architecture and deploy it!
When you have developers working alongside
Operations, you get DevOps!
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency Docker Conclusion
30. Change + Visual Management – Part I
Communicating/disseminating our plan:
• Roadmap
How are we going to get from our current state to our future state?
What are our requirements and assumptions?
How does our future state link to our business and quality values?
How do we measure success?
• Elevator speech – consistent messaging/signaling during scrums and meetings
What did we agree on and how did we make this decision?
What does the future state look like?
Why are we making the change?
How does everyone fit into the planning and execution of the future state?
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
31. Change + Visual Management – Part II
Tracking our progress and keeping ourselves accountable using visual management
tools:
• SWOT analysis/pre-assessment
• SMART objectives and action items
• Desired outcome
• Tool, service, framework, or process to achieve the item
• Responsible parties (RASCI matrix)
• Key milestones
• Due dates
• Measures of success
Overview Microservices Shifting Architecture Continuous Integration, Delivery Concurrency App Service Conclusion
Middleware is the green section. The bottom part – Presentation Logic Tier, Business Logic Tier and Data Access Tier explains the responsibility of Middleware.
A set of recommendations for how to build software as service.
Here are some of the predictable challenges.
What you’re looking at are the microservices architecture for 3 different companies.
The Netflix death star is what powers Netflix today.
The reason why millions of people can watch high-bandwidth, high-quality movies is because of this microservices architecture. The same applies for Gilt and Twitter.
Because of how the 12-factor app is architected, it will be very difficult to have a successful 12-factor app without an API management platform. That’s why we are going to discuss what it is and how it can help.
The main purpose of this slide is to give a high-level overview of the role of an API management platform.
What we’re seeing here is a conceptual strategy for how to implement an API management platform and at the same time have services that are from before the adoption of the API management framework.
The main idea is that the strangler is the as-is architecture and the API gateway is where newer APIs are deployed, where APIs that are stranglers are eventually migrated to.
The ambassadors are reusable logic that is deployed alongside each microservices, whereas a sidecar might be logic that pertains to that specific microservice.
The microservice is the definition of the API.
Now, I have taken the previous slide showing a conceptual architecture and this one is meant to represent an example closer to home.
Traditionally 3-tier architecture have 3 layers:
The presentation, which is HTML or XAML.
The logic tier, which is middleware.
And, the data tier, which comprise the databases.
The core of a 12-factor app is a hexagonal architecture.
It is self-hosted and communicates with other components through port-binding.
Its configuration does not reside in the application itself, but externally.
And, it’s data storage is swappable without affecting the app.
This can be achieved through a microservices architecture.
Here is an example of how a 12-factor app may segregate its logic for reading and writing.
Now, this particular architecture is built for speed.
So over here, we have the API gateway, which segregates, reads, and writes.
If it is a write, it goes through a middleware and eventually is saved into SQL Server.
At the same time, it is saved into a message queue and eventually the microservice is a subscriber of that topic and passes the results to Redis.
When a read operation occurs, it is routed to the read microservice, in which case, it utilizes Redis for an extremely fast experience and dataset results.
This is due to Redis reads being much faster than relational databases.
A 12-factor app can be deployed to any environment readily and reliably.
A solution that was proposed and accepted recently by FTFCU utilizes Octopus Deploy, Team City, and GitHub for continuous integration and continuous delivery.
This helps us achieve one of the fundamental goals of a 12-factor application.
A 12-factor app declares all of its dependencies within itself.
This can be achieved through a NuGet service and the utilization of NPM packages.
Today we are storing NuGet packages in a shared drive.
However, in my opinion, a more compelling alternative is to utilize the Team City NuGet repository to host the packages.
In order to achieve the 12-factor app desire to separate the configuration from the application, once again, Octopus deploy can help us store and orchestrate our configurations for each environment; that is, dev, QA, staging, and production, automatically.
A 12-factor application requires resources, such as databases, be detached and re-attached without code changes.
But, let’s think about a scenario where a database is in a different server and therefore, your connections strings that are controlled, as mentioned before, have to point to a generic end point.
This can be achieved through an Octopus deploy step to update the configurations.
Many applications today require complex logic in the background to occur, such that simply asking a potential user of the application to wait until those processes are completed would result in an undesirable user experience.
A common scenario for this type of process is a credit card application, where a decision may take sometimes hours or even days to complete.
Currently, we solve this problem by utilizing BizTalk. An alternative approach is to utilize Azure Logic Apps.
Logic Apps can connect to on-prem resources, as well as to any cloud providers, including our own cloud infrastructure.
It also provides common connectors that expedite communication between many cloud apps, such as Salesforce, FTP, SQL Server, SharePoint, Twitter, etc.
Here is an example of what a Logic App look like within Azure.
Another requirement of a 12-factor app is that it can be scaled up or down.
Docker is a platform that facilitates the scaling of the 12-factor application.
For more info, see: https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-autoscale
So even though we might want to start this today, there are a few considerations to explore:
We need the tooling
Training for both the developers, infrastructure, security, and CBA
More importantly, it’s about changing the culture from silos to teams that are together responsible for the success of a 12-factor app and the microservices that power it.
This vision can not be achieved in a silo and this is what we are going to do as an organization.
We, IT and the business, must join together to address these questions.
Enterprise architecture can guide the organization through a path to success, but can not alone dictate the solution to these concerns.