Today, I passed my TOGAF Essentials 2018 assessment...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:
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
If you're interested in keeping current with the last TOGAF Standard Version 9,2 courses, please reach out to me. :-)rwotertAod 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:
Large Solution SAFe
Still not convinced.....well there are a wealth of case studies on the SAFe site:
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:
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:
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:
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:
IBM is a little way behind the Top 2 leaders with their suite of cloud offerings. IBM Watson is probably the best known. I'm still waiting for IBM to approach me to, and invite me to their conference. Check out the screenshot below:
More information on IBM cloud services can be found here:
Alibaba are a definitely one to watch. My prediction, is that by 2020 Alibaba will be No. 3 by revenue and may well be looking to eat up AWS with a takeover strategy, to compete with Microsoft. Here is a quick overview of the predicted growth of Alibaba revenue vs AWS:
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:
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:
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:
#CloudComputing #Cloud #AWS #Amazon #Microsoft #Azure #Office365 #CyberSecurity #CCSP #Training #Coaching #AI
In the past 6 months, 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?
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
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:
We can also do the same on Azure:
Again, the documentation around Azure Blob storage shows the APIs are well-defined:
If we look to the certified cloud security professional (CCSP) best practices, we can see some common themes that apply to microservices:
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.
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
Azure Key Vault / AWS Key Management Service / AWS CloudHSM
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.
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
Azure Security Centre / Azure API Management
AWS Inspector / AWS Vulnerability / Penetration Testing
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:
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.
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….
Paul Colmer is a lead digital architect and cloud instructor for ALC training and consulting: www.alctraining.com.au/courses/cloud-computing/
Paul Colmer is a digital coach for ALC training and consulting, with a real passion for learning and applying disruptive technologies. Paul has responsibility for building and delivering ALC's digital architecture strategy and the development and execution of a number of cloud courses, including Cloud Security (CCSP), Amazon AWS, DevOps, Microsoft Azure and Office 365.