Sat the AWS Certified DevOps Engineer - Professional Exam last this afternoon.  The exam is hard, as it scenario based.   Most of the exam questions were to pick the best solution for deployments which comprised CloudFormation, Elastic Beanstalk and OpsWorks.   Every one of those questions had 2 good answers, it came down to which was more correct based on the keywords cost, speed, redundancy, roll back capabilities.  

I did the course on acloud.guru and a lot of AWS pages. At some point I will make a page of all the links I collected when studying for this exam.

The exam took me about two-thirds of the allowed time, I read fast and have a tendency to flag questions I don’t know the answer to and come back later and work thru them. This exam, I flagged 20 questions. Most of them I could figure out, once I thought about them for a while. But flagging questions and going back helps manage the time.

Upon submission, I got the “Congratulations! You have successfully completed the AWS Certified DevOps Engineer - Professional…”

I got my score email very quickly:

Overall Score: 82%

Topic Level Scoring:

That now makes my 7th AWS Certification.

Last week, I got the privilege to attend an Item Development Workshop for the Associate Architect Exam.   I participated as a Subject Matter Expert as the certification program pulls both Amazonians and industry professionals together to develop questions.   I’m not going to go into details about the workshop or share any content, because of the NDA.  I do want to share 3 observations I found during my time in the in the workshop:

1. AWS takes certification, the validity of certification and the value of certifications with immense regard.   The program is designed to recognize those who have AWS knowledge.  As the certification is not about memorization but the ability to learn, understand and apply.
2. The AWS certification team is amazing.
3. AWS people are very intelligent and have a deep understand of both AWS and technology.  

The experience was a learning fascinating experience and hope to continue to participate as an SME for other workshops.  

I was listening to the Architech podcast.  There was a question asked, ”Does everything today tie back to Kubernetes?”   The more general version of the question is, “Does everything today tie back to containers?”.    The answer is quickly becoming yes.    Something Google figured out years ago with its environment that everything was containerized is becoming mainstream.

To support this  Amazon now has 3 different Container technologies and one in the works.

ECS which is Amazon’s first container offering.    ECS is container orchestration which supports Docker containers.    

Fairgate ECS which is managed offering of ECS where all you do is deploy Docker images and AWS owns full management.  More exciting is that  Fairgate for EKS has been announced and pending release.  This will be a fully managed Kubernetes.    

EKS is the latest offering which was GA’d in June.   This is a fully managed control plane for Kubernetes.   The worker nodes are EC2 instances you manage, which can run an Amazon Linux AMI or one you create.

Lately, I’ve been exploring EKS so that will be the next blog article, how to get started on EKS.

In the meantime, what have you containerized today?

A new study sponsored by Capsule8, Duo Security, and Signal Sciences was published about Cloud Native Application Security.   Cloud Native Applications are applications specifically built for the Cloud.  The study entitled,  The State of Cloud Native Security.  The observations and conclusions of the survey are interesting.   What was surprising is the complete lack of discussion of moving the traditional SECOPS to a SecDevOps model.  

The other item, which found shocking with all the recent breaches, that page 22 shows that only  71% of the surveyed companies have a SECOPs function. 

DevOps is well defined and has a great definition Wikipedia. We could argue all day about who is really doing DevOps(see this post for context). Let’s assume that there is efficient and effective DevOps organization, If this is the case, DevOps requires a partner in security. Security needs to manage compliance, security governance, requirements and risks. This requires functions in development, operations and analysis. How can security keep up with effective DevOps? Building DevOps organization for security which we call SecDevOps. SecDevOps is about automating and monitoring compliance, security governance, requirements and risks, and especially updating analysis as DevOps changes the environment.

As organization support DevOps but don’t seem as ready to support SecDevOps, how can security organization evolve to support DevOps?

Open source has been around for decades, but the real initiatives started in 1998. Due to some recent experiences, I started pondering open source and the future of software.

I believe the future of software is open source where a company which wraps enterprise support around it.

Take any open source software,  if you need a feature typically someone has built it.  If they haven’t, your team ends up creating it and adding it back to the project.    Open source has the power of community vs a company with a product manager and deadlines to ship based on some roadmap built by committee.  I made it too simple, open source has a product manager, really in most communities they are gate keeper.   They own accepting features and setting direction,  in some cases it’s the original developer like Linux, or sometimes it’s a committee,  However, at the end of the day either commercial or open source has a product owner.

It’s an interesting paradux which created two opposing questions. First, why isn’t all software open sourced?   Why would a company who has spent millions In development going to give the software away and charge for services?

The answer to the first question is see question two.  The answer to the second question is giving away software is not financially viable if millions have been invested unless a robust software support model is supporting the development of software.

I worked for many organizations who’s IT budget was lean and agile,   Open source was was minimal budget dollars.  I have worked for other organizations whose budget is exceptionally robust and requires supported software as part of governance.

Why not replace the license model with a support model, and allow me or even more importantly the community access to the source code, contribute and drive innovation. Based on users, revenue or some other metric charge me for support or allow me to opt out. Seems like a reasonable future to me.