Contino - Enterprise DevOps Transformation on Andrew Khoury

AWS 2021 Highlights

Fri, 27 Aug 2021 14:37:40 +0000

AWS updates their services so quickly they literally have thousands of updates each year (1,284 the last time I checked): https://aws.amazon.com/about-aws/whats-new/2021/

This blog will highlight some of my favorite AWS updates for 2021.

AWS Network Firewall

https://aws.amazon.com/network-firewall/ — A managed service by AWS that allows fine-grained control over network traffic.

Before Network Firewall was available, customers were left to manage their own squid proxy or similar service if they wanted fine-grained control over their traffic in the Cloud (like many Enterprise customers do). This meant ensuring their service met security and compliance requirements, traffic and scaling demands, and uptime SLA’s, all while adding to the burden for operational teams. Some routed traffic back to on-premise solutions, but this wasn’t always a viable solution for all customers.

AWS Network Firewall became available in Sydney back in January: https://aws.amazon.com/about-aws/whats-new/2021/01/aws-network-firewall-is-now-available-in-the-asia-pacific-sydney-region/

It received a few updates and deployments to other regions. In April, they rolled out to 10 more regions. By June, it was available as part of AWS GovCloud (US), and by the end of July, it was PCI DSS Compliant.

Amazon EBS io2 Block Express Volumes

If you have the need for speed (that is, I/O speed), then this is the update for you. In July, AWS launched a special kind of volume that is perfect for I/O intensive operations. This isn’t intended for your typical web server with a few hundred concurrent connections, but plenty of Enterprise clients may find themselves needing a little bit of extra grunt.

https://aws.amazon.com/about-aws/whats-new/2021/07/aws-announces-general-availability-amazon-ebs-block-express-volumes/

up to 4x higher throughput, IOPS, and capacity than io2 volumes
designed to deliver sub-millisecond latency
99.999% durability
Supports Multi-Attach and Elastic Volumes

Customers can now provision a single io2 volume with up to 256,000 IOPS, 4000 MB/s of throughput, and a storage capacity of 64 TiB.

PrivateLink for Amazon S3

As of February, Amazon S3 supported AWS PrivateLink, providing direct access to S3 via a private endpoint within your virtual private network.

https://aws.amazon.com/about-aws/whats-new/2021/02/amazon-s3-now-supports-aws-privatelink/

Simplify your network architecture by connecting to S3 from on-premises
In AWS, use private IP addresses in your Virtual Private Cloud (VPC) to connect to S3

This eliminates the need to use public IPs, configure firewall rules, or configure an Internet Gateway to connect to S3.

As of July, AWS also lowered the data processing cost for PrivateLink (phew): https://aws.amazon.com/about-aws/whats-new/2021/07/aws-lowers-data-processing-charges-aws-privatelink/.

Summary

Each of these updates has been something I’ve personally been waiting for or had to work around in the past. They also represent a nice cross-section of services that you’re likely to encounter if you dive deep enough into AWS.

AWS continues to roll out updates across its services which reduces the effort required to enter the Cloud. They continue to deliver services that cater to the speed and scale we could only have dreamt of 15 years ago (oh and Happy Birthday AWS/EC2).

Info

Also posted on medium as AWS 2021 Highlights.

Principals for (Technical) Principals

Sat, 04 Apr 2020 17:29:33 +0000

Join me on an exploration of all things consulting & leadership and all the fun stuff in-between.

I have a love of technology, with a passion for optimizing both code & process. I also love to teach and for me that usually means pairing or getting in front of a whiteboard.

I’m currently playing the role of Technical Principal Consultant. You might know this role by another name, or you may notice it’s similarity to other roles (Technical Principal, Account Principal, Technology Evangelist, Delivery Lead, Principal Consultant, Solutions Architect, Technical Team Lead, Agile Transformation Leader).

The reason why I say “playing the role” is because many technical or transformational leadership roles share the same DNA and have more cross-over that you might think.

In this article we’re going to explore three things:

What makes a successful consultant
What’s important for a Technical Principal role?
What’s important for other leadership roles?

What makes a successful Consultant?

Often categorized as “soft-skills” there are some basic “consulting-101” things that you’ll need to be a successful consultant. As a consultant it is important to understand and harness these skills, and they’re particularly important in “Principal” or “Leadership” roles. The following isn’t meant to be an exhaustive list and people aren’t magically born with all these skills so it’s best to treat them as a guide for self-improvement.

The attributes to look for in a Principal Consultant or Leader are:

Influencing (conviction, empathy, able to rapidly build trust with their team and stakeholders)
Awareness (situational awareness, reading a room, control)
Collaboration (open, honest, respectful, servant leadership)

So what does a “successful consultant” look like? Are we expected to excel in all areas 100% of the time? As it turns out these skills can be complicated to test for (especially in 1 hr interviews) however they tend to be easily demonstrated when the rubber hits the road.

Let’s visualize what we’re looking for:

Now we have some favorable attributes that we’re looking for & our consultants know what they should do more of. Each of one of us in our own journey and the key is to identify areas for improvement and start to demonstrate progress there. Your company should support you in identifying areas to improve and provide mentorship as well as opportunities to grow and succeed.

Technical Leadership

I’m a technical leader, can’t I just stick to the tech?

Should Technical Leaders just focus on technology? In my opinion the answer is no, and the key is in the word leader. As technical leaders (and this is especially true for those of us in consulting) our job is so much more than “hands on keyboard”. So while you can code and you might get your hands dirty from time to time, your primary role should be to support your team in making the best decisions they can at the time and getting out of their way while they work their magic (and for anyone that’s tried to do that, it’s harder than it seems).

Let’s have a look at what skills a Technical Principal might posses in addition to the above consulting skills that we expect every consultant to have.

We’re typically going to expect higher competency in “Technical Team Leadership” and “Solution Design & Architecture” from someone in a Technical Principal role. Skills like “Strong Communication” and “Trusted Strategic Advisor” should also be demonstrated but it’s be okay for some people in this role to have some growth in that area.

Pillars

The pillars mentioned above are:

Strong Communicator

Awareness & Influence

Trusted Strategic Advisor

Empathy, can relate tech back to business value, understands the “why” of whatever we’re choosing to do, pragmatic & flexible

Technical Team Leadership

Charisma, Experience in successful delivery

Solution Design & Architecture

Passionate about technology & knows what good looks like, can be hands on but sees their primary role as supporting their team who are the real “doers”

Other leadership roles

As we mentioned at the start there are many roles that share similar DNA and they usually have the words “Principal” or “Leader” in them.

Let’s take a look at our Pillars for a Technical Principal and apply them to a different leadership role for comparison. We’ll pick an “Account Principal” which is a role you might see from a consultancy — someone who’s responsible for the health of the account, successful delivery of outcomes, and has accountability for the financials of an Account…

Here we’ve used the same pillars due to the cross-over between roles but we’ve changed the “pass mark” to favor strong communication and being a trusted strategic advisor. We’ve also lowered our expectations around technical leadership and solution architecture (they’re nice to have’s and you may possess those skills in this role but on larger accounts you’d expect to be able to pair with Technical Principals for those gaps).

Account Principals are also more likely to be involved in the financial health of an account, client happiness and overall team health along with responsibility for the delivery outcomes. Smaller accounts may allow the flexibility to have one person play both roles but as accounts get larger focus becomes important and the need for specialized skills becomes important.

The most successful accounts I’ve worked on have seen a strong partnership between these Technical and Account roles with less concern about who “should” be doing what and more focus on:

How can we help each other
How can we compliment our respective strengths/weaknesses
How can we encourage personal growth within each other

What’s the take away?

For niche consulting in particular, there exists a fundamental set of “soft-skills” that are critical to a team’s success.

For anyone playing the role of “lead” or “principal” it’s important to bring these skills (and your experience) to the table as an asset that will help them through difficult situations, and as skills they can learn to improve themselves as individuals.

It’s important to have a whole-team understanding of what we need (and don’t need) from each role, and uplift each other by leaning on each other’s strengths rather than aiming for individual success.

So what’s the difference between roles like “Technical Principal” and other leadership roles?

…Hopefully you’ll now agree, not as much as you originally thought.

Info

Also posted on medium as Principles for (Technical) Principals and on Contino as How to Be a Technical Leader: The Principles Behind Successful IT Consulting

The True Cost of Being Cloud-Agnostic

Wed, 09 Oct 2019 01:41:01 +0000

Let’s talk about the real cost of cloud computing, and by that I don’t mean hourly pricing models, network charges, and licencing implications.

I want to talk about opportunity cost, explore factors like speed to market, how effective our development teams can be, and the operational overheads involved in our technology choices.

The famous Allan Denot once said…

“If you believe in the cloud, you can’t be agnostic.”

…and by famous I mean in DevOps/Sydney, and by once I mean January 2019.

I believe in the cloud! When I make that statement, it doesn’t mean I promote “only using the services that are available in all clouds” or “building all of your own services from scratch so they work identically in each cloud”.

I’m a firm believer in using the right tool for the right job, and the right cloud or clouds for your project, program or organisation. I’m a cloud believer and I don’t have a vested interest in any one cloud.

There are many ways “the cloud” can make your life easier. If you’re looking for a simple way to store and retrieve files, and you’re okay with it taking a few seconds, not a few milliseconds, AWS S3 is a great option. AWS RDS is an ideal way to use the relational database that you know and love without having to be hands-on with installation, upgrades, and replication. Are you a Microsoft shop? It’s hard to pass up Azure for services like hosted Active Directory. Do you only care about writing code? Google App Engine is an amazing service for Planet-Scale web services with all of the infrastructure managed for you.

But what about the other definition of being cloud-agnostic? What about the dream of many organisations that we keep hearing so much about in the industry…

Cloud-agnosticism is great! No vendor lock-in, more customisation, but wait. Think of all those tightly integrated managed services you’re leaving behind.

If you read the article by by Maish Saidel-Keesing called “ Cloud-Agnostic: Friend or Foe?” this provides some great insights into this topic.

Trying to be cloud-agnostic may lead you to “only use features that are available in all clouds”, which is the lowest common denominator, or “deploy in such a way that we can switch a given workload to any cloud in minutes depending on the hourly price of a given service”, which I’ve not yet seen an organisation achieve.

The scary path I’ve seen too many organisations follow is the idea that we should build as much of the system as possible in-house to avoid any sort of lock-in.

The avoidance of cloud vendor products or even third party SaaS products for fear of being locked-in has been a common theme with the organisations I’ve worked with. I’ve never found the right way to describe the flaw with this way of thinking until I came across the following article which compared cloud provider lock-in to databases:

“If we choose to use Oracle as the database for a given application, we don’t usually also build the application on SQL Server to make sure we aren’t locked in to Oracle. We don’t do so simply because we believe that the costs of having two alternative databases for the same application will outweigh the benefits in risk management.”

“ Switching Costs and Lock-In” is a great AWS blog that explains the difference between switching-costs vs lock-in.

If cloud-agnostic is the “wrong strategy”, what is the right one?

It would be foolish of me to prescribe a magic bullet for your cloud journey. Having a well thought out application migration strategy and a shared vision for the future of your application architecture should be a key part of your strategy. If I only had a few minutes to set you on the right path I’d ask you to consider the following:

Some of the most successful projects I’ve had the pleasure of being part of have taken advantage of the hard work of cloud or SaaS providers. They help organisations save time, and allow them to get things done right the first time.

Cloud native, serverless and SaaS are some of the most powerful ways to add value to a DevOps/ cloud transformation, outside of the people-part of the transformation. Services like RDS, S3, Google App Engine, Buildkite, Github, and Slack are among my favourite technical accelerators to help drive success in organisations.

Is missed opportunity the real cost?

At this point you may still be asking yourself, what’s the true cost of being cloud-agnostic? Is it cheaper, or more expensive than the alternative? The cost I’m referring isn’t directly related to your profit and loss statement. In fact, the true cost of trying to be cloud-agnostic can be missed opportunity and revenue, stifling innovation, project delays, and missing out on a selection of some of the most useful services the cloud has to offer.

So here I stand, a Cloud Believer using the “best of breed” way of thinking and continuous improvement to help you get the most out of the cloud. After all if you believe in the cloud, you can’t be agnostic.

Info

Also posted on medium as The True Cost of Being Cloud-Agnostic and Contino as The True Cost of Being Cloud-Agnostic.