I'm consistently seeing twitter feeds with #Microservices embedded in the tweets.  So, what are microservices, what value do they add to my business and how do I secure them, if I decide to adopt them? 
​
MicroServices
 
Firstly, microservices and REST, are architectural approaches to developing code.  So, let me cover what REST is, and then microservices becomes a little easier to understand. 
 
In the Certified Cloud Security Professional course that I run, there is a specific section under Cloud Application Security, where the learning outcome is to describe specific cloud application architecture and to understand the application programming interface (API) structures. 
 
Below is a diagram that outlines the 2 types of APIs that we consider in the course:

To summarise, SOAP is a protocol for exchanging structure information, whereas REST is an architectural style that relies on stateless, cache less protocols.  Put simply REST is a way of Creating (using the POST verb), Reading (using the GET verb), Updating (using the PUT verb) and Deleting (using the delete verb).
 
Let's extend this concept a little further and we'll start to understand Microservices.  With REST, we can see that the commands, or verbs, are very simple.  This means it's easy to create small independent services.  Principle 1 of Microservices.
 
By ensuring that our APIs are clearly documented and follow this RESTful style, we form the basis of creating well-defined, lightweight APIs.  Principle 2 of Microservices.
 
And finally, by using REST, i.e. POST, GET, PUT, DELETE we are using an HTTP resource API.  Principle 3 of Microservices.
 
Let's expand out those 3 key principles and explore what they mean:

P1 - Create Small Independent Services.
Independence means that we do not need a centralised datastore, instead the data is distributed and when we change one of our services, it does not require other services to be changed.  This is referred to as loose-coupling.
Small means that each we focus on a very small set of capabilities that focus on a specific domain.  Ideally a single capability.

P2 - Create well-defined, lightweight APIs.
Well-defined means that I clearly document how to call the API.  Lightweight referring to the small range of functions that I can execute to achieve my outcome.

P3 - Using an HTTP resource API where possible.
This means we are using HTTP commands, i.e. POST, GET, PUT DELETE in a RESTful manner.

Here is a piece of code below that follow the 3 principles using AWS.  It deletes a jpeg picture file, called dodgy picture, from storage on AWS.  The storage is simple storage service, or S3 for short, and we refer to the container that holds the jpeg, as a bucket:
 
DELETE /dodgy_picture.jpg HTTP/1.1
Host: examplebucket.s3-us-west-2.amazonaws.com
Date: Mon, 11 Apr 2016 12:00:00 GMT
x-amz-date: Mon, 11 Apr 2016 12:00:00 GMT
Authorization: authorization string

In this case, we can see it is a Small Independent Service, it uses an HTTP resource API, it is lightweight and it is well-defined, as exemplified by the AWS S3 documentation:
 
http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html
 
We can also do the same on Azure.
 
Again, the documentation around Azure Blob storage shows the APIs are well-defined:
 
https://docs.microsoft.com/en-us/rest/api/storageservices/blob-service-rest-api

Security
 
If we look to the certified cloud security professional (CCSP) best practices, we can see some common themes that apply to microservices:
 
Secure APIs
To provide unauthorised access to the data, leading to data loss, data breach or service hijacking, it's best to implement a method of ensuring that the API calls you receive are authenticated.  In other words, they are authorised to make the call and access your data.
 
This can be achieved using an API gateway service, such as AWS API Gateway or Azure API Management, most likely linked to a directory service, such as Microsoft Active Directory or AWS Cloud Directory service.

Protect Data
To protect the data in transit between the two API calls, it's worth considering virtual private network (VPN) technologies, such as Azure VPN Gateway or AWS VPN CloudHub. 
 
To protect data at rest you can use encryption.  Encryption requires the exchange of keys and the keys need to be secured in a safe place.  Remember if the location is too safe, and you cannot find the keys, you cannot unencrypt the data.  Which means you're prone to data loss. 
 
Data in Motion
Azure VPN Gateway / AWS VPN CloudHub
 
Data at Rest
Azure Storage Service Encryption / AWS S3 Server-Side Encryption
 
Key Management
Azure Key Vault / AWS Key Management Service / AWS CloudHSM

Monitor
Enable application logging on all your API's so you can see that they are behaving as required.  Logging at the infrastructure level can also reveal vulnerabilities that may affect the way APIs are called.  At both levels, you should be centralising all your logs into a SIEM (Security Information and Event Management) system.
 
SIEM
Azure Log Integration / Azure Operations Management Suite - Log Analytics / AWS Kinesis / AWS ElasticSearch
 
The OWASP Top 10 outlines application best practices to avoid common vulnerabilities that can be introduced as part of a software development lifecycle.  There are various tools that can be used to help detect the OWASP vulnerabilities:
 
OWASP Detection Tools
Amazon Web Application Firewall / Azure Application Gateway
 
Vulnerability Assessment
Azure Security Centre / Azure API Management
AWS Inspector / AWS Vulnerability / Penetration Testing
​

​Business Value
 
By adopting the 3 principles we outlined above and incorporating the key security best practices, we can clearly see that we're helping the business in many ways:
 
Faster Value
Adopting a microservices architecture, allows us to develop services quickly and scale them as required.  When this is\ combined with agile storyboarding and agile prototyping techniques, our clients can clearly see tangible results within weeks.
 
Higher Efficiency
The probability of wastage decreases rapidly by adopting a microservices architecture, since we are focused on creating functions that our clients absolutely need.  By enabling secure API communications coupled with logging, we can provide quality assurances back to the business using analytics. 
 
We also have the freedom to fail-fast which means we can innovate and try out new things.  And because our architecture is comprised of small, loosely-coupled components, we can roll-out new versions or releases of services, in a DevOps manner, on a weekly basis, rather than performing this on a monolithic scale every few months or years.
 
Finally, we can take microservices further by utilising serverless architectures, such as AWS Lambda or Azure Functions.  This reduces the need for our developers to worry about the size and scale of the virtual machine and storage infrastructure and instead focus on writing reliable, scalable and easy to understand code.
 
Another concept we can utilise is containerisation, using Docker, which effectively builds us a consistent environment that we can port between test, pre-production and production without introducing those nasty regressions, or unintended bugs.  Docker manifests itself as AWS EC2 Container service or Azure Container Service.
 
Both serverless architectures and containerisation concepts are blog posts, so I’ll cover them in future blog editions.
 
What are you waiting for?  Let's move to microservices….

I passed my TOGAF Essentials 2018 assessment this year...but why?  Well I run coaching and mentoring masterclasses, covering a range of new digital courses.  The most popular at the moment is the Certified Cloud Security Professional course (CCSP), which leads the CCSP certification endorsed by the ISC2.  The next most popular is the TOGAF standard, a standard of the Open Group.  As an instructor, I have to maintain my currency on all the latest materials and the TOGAF Essentials 2018 assessment is a great way of doing that.  It basically makes clear all the differences between the TOGAF Standard Version 9.1, from 2011 and the TOGAF Standard Version 9.2 standard which was released only a few weeks ago.

So let's cut to the chase.  What are some of the key differences:

1. Content in the tools / techniques section, such as Business Scenarios, have been removed from the TOGAF standard and separated out into separate guides in the TOGAF Library.  THis makes them easier to maintain, aligning to a more #Agile approach.
2. New Guides have been added that covers things like Value Streams, Business Capabilities and Establishing an EA capability.
3. Security, SOA and the Reference Models are now in separate documents and removed from teh core book.
4. Business Architecture, Phase B, has been strengthened to include new definitions, which in turn has meant some changes to the content metamodel.  Examples include new definitions of Buiness Capability, Business Model and Value Stream.
5. Updates to basic architecture concepts that better align with the ISO/IEC/IEEE 42010:2011 standards.
6. Technology Platform is now known as Technology Services in the metamodel.
7. Enterprise Security Architecture aligns more closely with the Sherwood Applied Business Security Architecture, known as the SABSA framework.
8. Inconsistencies and errors in the ADM Phases has been rectified.
9. Architecture Repository view has been updated to now include the Solutions landscape and the Architecture Requirements Repository.

Overall I really welcome the changes, and it's good to see the TOGAF standard being broken into smaller artifacts, so that they can be updated independently.  Great to see the Open Group slowly moving to a more Agile approach.

I've also released a FREE set of flashcards specifically to help you remember all the TOGAF 9.2 terminology for the Part 1 and Part 2 exams.  Check them out on Quizlet:   quizlet.com/_57zkpz

Check out our course at ALC Training:

​www.alctraining.com.au/course/togaf-9-level-1-2-certificate-course/wotertAod ApplieThered Business SBusinecurity ArchitectureSherwood Applied Business Security Architecture

TOGAF(R) is a registered trademark of the Open Group.

Scaled Agile Framework, or SAFe for short, is a large interactive knowledge-based of best practices, case studies, courses and toolkits.  The patterns and resources are proven, backed up by numberous case studies.  It is specifically designed to work for very small businesses, right through to multi-billion dollar corporate giants.  How does it do that? 

Well there are a number of components that allow the method to scale.  This includes a list of the key principles, outlined above, but also used the concept of Agile Release Trains.  These are teams of teams, containing all your resources, including suppliers and partners, that are co-ordinated through program increment (PI) planning.  These planning sessions ensure all the trains are moving in the same direction and that all the work is decomposed into features and stories.  This results in working code shortly after the first sprint.

The framework itself comes in four flavours:

1. Essential SAFe
2. Portfolio SAFe
3. Large Solution SAFe
4. Full Safe

The order and selection of the above configurations is highly dependent on the organisation's vision, committment and maturity to adopting Agile.  Below are all the frameworks for comparison.

Still not convinced.....well there are a wealth of case studies on the SAFe site:

www.scaledagileframework.com/case-studies/

Below is are a few of my favourites:

Want to know more about how to use SAFe?  Please check out my Leading SAFe 2 Day Course.  Please let myself or ALC Training know when and where we can run this course for your organisation:

For the first time in 2018, it's become easier than ever to gauge the state of the cloud market.  New data from the top cloud providers, mean we can really see who is dominating the landscape.  In this blog, I've chosen to look at the total revenue as an indicator of success.  Partly because it's easy to measure, but also because it given an indication of relative market opportunity and growth.

This chart is taken from a great ZDNET article that was published earlier this year:
www.zdnet.com/article/cloud-providers-ranking-2018-how-aws-microsoft-google-cloud-platform-ibm-cloud-oracle-alibaba-stack/

It clearly shows Microsoft as the dominant force, which I predicted would be the case back in 2016.  My colleagues at DXC Technology will attest to that prediction.  I think it's also a reflection on a number of compelling events that have materialised over the past few years:

• Microsoft have invested significant amounts of money into their cloud strategy and you can see it's paying off.   www.onmsft.com/news/microsoft-spending-more-10b-year-azure-data-centers
• Microsoft's cloud portal was reskinned around 3 years ago, which put AWS on the back foot.  azuretalk.wordpress.com/2015/02/24/azure-portal-new-look-and-feel/
• All medium and large corporate companies of note, already have a relationship with MIcrosoft through an Enterprise Agreement (EA).  This EA provides Microsoft with significant scope for commercial leverage, through price reductions, discounts and bundled services, across the Azure and Office 365 platforms.  en.wikipedia.org/wiki/Microsoft_Enterprise_Agreement
• Office 365 is a serious force to be reckoned with.  There is no real competition in this space and the vast majority, if not all companies, use some components of the product suite.  Integrated with Active Directory technologies for authentication, authorisation and access control.

Although Google offers their G-Suite, I don't really see it as a serious competitor or replacement for Office 365. In fact they complement each other.  I typically use Google for managing both business and personal data on my Google Pixel and then Office 365 for Surface Pro, MAC and iPad and then OneDrive across all of them.  Below is a quick snapshot of how Google and Office stack up:

On the Amazon Web Services side, there is much progress and improvement especially in the area of new services.  AWS are very good in the Serverless and PaaS spaces, adding a whole series of new innovations.  These and exciting innovations were announced at the AWS ReInvent 2017 conference last year and include:

• AWS Fargate - Serverless Containers
• Amazon ECS for Kubernetes - Container Management
• Amazon Neptune - Graph Database
• Amazon Sumerian - Create and run 3D apps for Virtual Reality & Augemented Reality Use Cases
• AWS IoT Analytics - Analyse IoT data at scale
• Amazon Rekognition Video - Video Analysis using Machine Learning

You definitely can not accuse Amazon of being static, boring, with all this innovation coming thick and fast.  Amazon are certainly pushing the curve, as there are no Microsoft Azure equivalents for some of these services.  Amazon Sumerian is a case in point.  See the screenshot below:

Oracle are coming up fast, probably as a result of their push in the past 12-18 months.  A rep at Oracle invited me to attend Oracle Cloud World, which introduced me to the maturity and sleek look of their latest cloud offerings.  The pics below gives a quick overview of the Oracle Cloud offerings:

And here is a good article that articulates how large and dangerous Alibaba really is.  I do apologise for all the popups, but the free content on the site IS worth the pain:
​www.cbinsights.com/research/amazon-alibaba-international-expansion/

The link below gives another perspective on the Microsoft / AWS revenue growth story, outlining some of the great customers stories to come out of the Azure platform.  These include:

• Coca Cola
• UPS
• Toyota

​www.forbes.com/sites/bobevans1/2018/04/27/microsoft-tops-amazon-in-q1-cloud-revenue-6-0-billion-to-5-44-billion-ibm-third-at-4-2-billion/#57a5358a5d4b

Finally if you feel you need some specialised training or business advice on AWS, Microsoft Azure, IBM, Oracle or Cloud CyberSecurity, feel free to reach out to me or to ALC Training:
www.alctraining.com.au/courses/cloud-computing/

#CloudComputing #Cloud #AWS #Amazon #Microsoft #Azure #Office365 #CyberSecurity #CCSP #Training #Coaching #AI