The AWS CLI run-instances documentation isn’t great on how to assign a public IP Address in a VPC when you create a new instance, so this is a quick note on how to do it.

There’s a bug report on Unable to use –associate-public-ip-address but the fix mentioned isn’t very clear on the formatting, but this command line works:

aws ec2 run-instances --image-id ami-f0b11187 --key-name your-ssh-key-name --instance-type t2.micro --network-interfaces '[ { "DeviceIndex": 0, "Groups": ["sg-123456"], "SubnetId": "subnet-123456", "DeleteOnTermination": true, "AssociatePublicIpAddress": true } ]'

You obviously need to change the “Groups” value to a valid security group in your own VPC, and SubnetID to a subnet-id in your VPC (plus pick the right AMI for image-id), but after that you will be able to create an instance with a public IP!

Technology, however good it is, will never give you a strategy, IT or otherwise, and your choice of a particular piece of technology over another is not a strategic decision.

I see this a lot recently in articles and blog posts.

Not IT Strategy

  • “We have containers as part of our IT strategy”
  • “VMware vSphere is our strategic platform”
  • “Embracing Java for development is our strategy”
  • “Our strategy is to move to micro-services”

These may all be sound technology choices, but they are reflections of strategic choices, not strategic decisions themselves.

The strategic decisions are things like the ones below

IT Strategy

  • Any IT systems that are revenue generating for the company will be developed in-house, to ensure we control our own destiny
  • We will move to an IT brokerage model, where business users will be directed to external suppliers for engagement of any required applications or services
  • Where a suitable option is available, all our existing and new applications will be migrated to an external SaaS platform

From these strategic decisions (and these are still fairly tactical in my mind), you will end up making a series of technical decisions, but please don’t confuse them for strategy themselves.

IT Strategy Outcomes

  • We use CloudFoundry, because we are rapidly switching to “Web-scale” application and operational models, and this choice accellerates and eases the transition
  • We use VMware vSphere, because we want to minimise the impact, and maximise the capabilities when transitioning from the legacy IT model of 1 server for 1 application, to a newer approach where hardware and software are decoupled
  • We keep much of our software development in-house to give us a competitive advantage over our competitors who use off-the-shelf packages, and needed a standard language in place to maximise code-reuse

If you remember one simple thing about technology and IT strategy, make it this:

If you mention a piece of technology, it’s almost certainly not strategy.

I love the metaphor of farm animals and pets, and entirely get the concept and why farm animals are a much better way to build services.

It seems however, some people who believe “farm animal” servers are the only ones that matter, and that supporting the pets in Openstack is redundant and a waste of effort.

As someone who works in an enterprise IT department that would love to embrace Openstack, I really only have one thing to say:

“Enterprise IT departments don’t get to choose the core applications that their business runs on.”

If Openstack is “farm animals only”, then you can guarantee that many (most?) IT departments will go elsewhere for their cloud infrastructure management, and when VMware and Microsoft finish collecting those invoice payments, there’ll be a lot less money coming into Openstack to pay for future developments.

I hope Openstack is pet friendly very soon, not because I love having them around, but because the transition to cloud from large, monolithic, scale-up applications is already hard enough, and having a unified infrastructure management would make it that bit easier for us all.