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.

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?

One of the things I’ve been fascinated of late is the concept of Security as Code.   I’ve just started to read the book DevOpSec by Jim Bird.   One of the things the book talks about is injecting security into the CI/CD pipeline for applications.  Basically merging developers and security, as DevOps merged developers and operations.   I’ve argued for years DevOps is a lot of things, but fundamentally it was a way for operations to become part of the development process which led to the automation of routine operational tasks and recovery.  So now if we look at DevOpsSec, this would assume security is part of the development process. I mean more than just the standard code analysis using Veracode.  What would it mean if security processes and recovery could be automated?  

Security Operations Centers (SOCs) where people are interpreting security events and reacting.  Over the last few years, much of the improvements in SOCs has been made via AI and machine learning reducing the head count required to operate a SOC.   What if security operations were automated?   Could some code be generated based on the security triggers and provided to the developer for review and incorporation into the next release?

We talk about infrastructure as code, where some data can be generated to create rules and infrastructure using automation.   Obviously on AWS you can install security tool based AMIs, Security Groups and NACLs with Cloudformation.  My thoughts go to firewall based AMIs, appliances  for external access.   The appliance access-lists required are complex, require enormous review and processing within an organization.  Could access lists be constructed based on a mapping of the code and automatically generated for review?  Could the generated access list be compared against existing access-list for deduplication detection.

It’s definitely an interesting topic and hopefully evolves over the next few years. 

Let’s start with some basics of software development.    It still seems no matter what methodology of software development lifecycle that is followed it includes some level of definition, development, QA, UAT, and Production Release.   Somewhere in the process, there is a merge of multiple items into a release.   This still means your release to production could be monolithic.

The mighty big players like  Google,  Facebook, and Netflix (click any of them to see their development process) have revolutionized the concept of Continous Integration (CI) and Continous Deployment (CD).

I want to question the future of CI/CD,  instead of consolidating a release, why not release a single item into production, validate over a defined period of time and push the next release.   This entire process would happen automatically based on a queue (FIFO) system.

Taking it to the world of corporate IT and SaaS Platforms.   I’m really thinking about software like Salesforce Commerce Cloud,  or Oracle’s NetSuite.      I would want the SaaS platform to provide me this FIFO system to load my user code updates.  The system would push and update the existing code, while it continues to handle the requests and the users wouldn’t see discrepancies.    Some validation would happen, the code would activate and a timer would start on the next release.  If validation failed the code could be rolled back automatically or manually.

Could this be a reality?

Serverless is becoming the 2018 technology hype.   I remember when containers were gaining traction in 2012, and Docker in 2013.  At technology conventions, all the cool developers were using containers.   It solved a lot of challenges, but it was not a silver bullet. (But that’s a blog article for another day.)

Today after an interview I was asking myself,  have Containers lived up to the hype?   They are great for CI/CD, getting rid of system administrator bottlenecks, helping with rapid deployment, and some would argue fundamental to DevOps.  So I started researching the hype.   People over at  Cloud Foundry published a container report in  2017 and 2016.

Per the 2016 report, “our survey, a majority of companies (53%) had either deployed (22%) or were in the process of evaluating (31%) containers.”

Per the 2017 report, “increase of 14 points among users and evaluators for a total of 67 percent using  (25%) or evaluating (42%).”

As a former technology VP/director/manager, I was always evaluating technology which had some potential to save costs, improve processes, speed development and improve production deployments.   But a 25% adaption rate and a 3% uptick over last year, is not moving the technology needle.

However, I am starting to see the same trend, Serverless is the new exciting technology which is going to solve the development challenges, save costs, improve the development process and you are cool if you’re using it.       But is it really Serverless or just a simpler way to use a container?

AWS Lambda is basically a container.  (Another blog article will dig into the underpinnings of Lambda.)   Where does the container run? ** A Server. **

Just means I don’t have to understand the underlying container, server etc.etc.etc.     So is it truly serverless?   Or is it just the 2018 technology hype to get all us development geeks excited, we don’t need to learn Docker or Kubernetes, or ask our Sysadmin friends provision us another server.

Let me know your thoughts.

Is DevOps the most overused word in technology right now?

The full definition from Wikipedia.  Here what DevOps really is about.   It about taking monolithic code with complex infrastructure supported by developers, operational personnel, testers, system administrators and simplifying it, monitoring it and taking automated corrective actions or notification.

It’s really about reducing resources who aren’t helping the business grow and using that headcount toward a position which can help revenue growth.

It’s done in 3 pieces.

Piece 1. The Infrastructure

It starts by simplifying the infrastructure build-out, whether it in the cloud where environments can be spun up and down instantly based on some known configuration like AWS CloudFormation,  using Docker or Kubernettes.   Recently, Function as a Service (FaaS), AWS Lambda,  Google Cloud Functions or Azure Functions. This reduces reliance on a DBA, Unix or Windows System Administrator and Network Engineers.   Now the developer has the space they need instantly.   The developer can deploy their code quicker, which speeds time to market.

Piece 2.  Re-use and Buy vs. Build

Piece 2 of this is the Re-use and Buy vs. Build.   Meaning if someone has a service re-use it, don’t go building your own.    An example is Auth0 for authentication and Google Maps for mapping locations or directions.

Piece 3.  When building or creating software do it as Microservices.

To simplify it you are going to implement microservices.   Basically, you create code that does one thing well.  It’s small, efficient and manageable.    It outputs JSON which can be parsed by upstream Services.   The JSON can extend without causing issues to upstream Services.   This now reduces the size of the code base a developer is touching, as it one service.   It reduces regression testing footprint.      So now the number of testers, unit tests, regression tests and integration tests have been shrunk.   This means faster releases to production, and also means a reduction in resources.

You’re not doing DevOps if any of these conditions apply?

1. You have monolithic software you’ve put some web services in front of.

2. Developers are still asking to provision environments to work.

3. People are still doing capacity planning and analysis.

4. NewRelic (or any other system)  is monitoring the environment, but no one is aware of what is happening.

5. Production pushes happen at most once a month because of the effort and amount of things which break.

Doing DevOps

1. Take the monolithic software and break it into web services.

2. Developers can provision environments per a Service Catalog as required.

3. Automate capacity analysis.

4. Automatic SLAs which trigger notifications and tickets.

5. NewRelic is monitoring the environment, and it providing data to systems which are self-correcting issues, and there are feedback loops on releases.

6. Consistently (multiple times a week)  pushing to production to enhance the customer experience.