Categories
All CTO/CIO Hiring

What does your dream job look like?

via GIPHY

I see this question a lot because I’m often on the lookout for new opportunities. So I speak with a lot of recruiters, hiring managers and CTOs. It’s an interesting question.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

When I think about it, there are a few ways to break it down. Here’s what differentiates firms for me.

1. What pace are you looking for?

Is the work-life balance the most important thing for you? That is do you want to leave at 5pm and not be oncall nights and weekends?

Alternatively are you after the fast-paced, always on, blistering hockey stick growth startup phase? That’s also exciting, although it may make work-life balance tougher.

Not to say the world is divided up into only two types, I do think this is an interesting way to divide up the world.

Related: Why I don’t work with recruiters

2. What engineering culture do you like?

Do you prefer an engineering organization, that is doing things cleanly, concisely, with truly best practices and high code quality, though perhaps with greater process control?

Or would you prefer more cowboy style, with less process and able to move quickly and get things out the door?

Related: How to hack job search?

3. What type of teams do you enjoy?

In some organizations that are smaller, you get a chance to wear a lot of hats. You aren’t so specialized because there are fewer total team members. For example there may not be one person devoted to the database work, and one developer takes on that responsibility. While there is not devops team, another developer automates infrastructure.

Alternatively do you prefer more clearly defined job roles? That may be a larger org that has many more engineers. In that way you can own your own tiny slice, and focus just on that skillset or tool.

Both are valid of course, but they may be different types of orgs or companies at different stages in their development.

Related: Questions to ask for a devops interview

4. What’s your overall motivation?

This is an interesting question. For me personally, I prefer to have the biggest business impact. If I can come into an organization and raise the bar, even if the bar wasn’t high to begin with, that is very satisfying. If I don’t get to use the coolest wiz-bang technologies that’s ok with me.

Alternatively there are some organizations that are facing much more challenging problems. These tend to be very hard technical problems, where the bar is already quite high. In those you may be surrounded by very talented engineers indeed, and the baseline for entry is already quite high.

Again both are valid, just a matter of what type of environment you thrive in.

Related: How to hire a developer that doesn’t suck?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Business Consulting CTO/CIO

How to find consulting clients?

via GIPHY

I get asked this question by people a lot. Whenever I attend conferences, meetups, or social events. How do you *do* consulting? I’d love to be doing that, how do I get there?

Join 38,000 others and follow Sean Hull on twitter @hullsean.

From what I can tell, the most important factor is being hungry. How do you teach that? If you’re fiercely independent to begin with, you may be willing to have a roomate, or do without luxury for a while, in order to build up your nest egg. To be sure you need some cushion to get started.

But you also need customers. Where the heck do you find them? Here are some tips…

1. What not to do?

The first thing you’ll find is that recruiters seem to have a lot of “customers”. Maybe I can just go that route. Sure, but just remember, those are not *your* customers. Your customer is the recruiting company. They have the relationship.

Why does this matter? Because you can’t build a business this way. You are effectively working as an employee of the recruiting company. Nothing wrong with it, but it’s not an entrepreneurial path. You don’t really have responsibility nor control over the full lifecycle of your business.

So again I would summarize, don’t use “hire a freelancer” sites.

And don’t use consulting headshops or recruiters.

Related: When you’re hired to solve a people problem

2. Do socialize

So how then? Well you need to first *peer* with economic buyers. What do I mean by that? Well if you go to technical conferences, that’s fine, but your peers are other engineers. These are not buyers. At best you may get a weak referral.

Hiring managers, CTOs, directors of operations, all will attend events where their peers will be found. If you want to be a professional services consultant, these folks are whom you need to socialize with.

First, experiment. Go to a lot of different types of events, meetups, small single track conferences. And ask where others go? What’s on their radar? Also introduce people to eachother. This may sound counterintuitive, but it’s important. Don’t have an agenda of “I’m looking for a job” but rather, I have a lot to offer.

Network by interviewing. This may appear to be an odd one, but it sometimes works. Take any interviews you can. Discuss how you solve problems. Learn by failing a few. If you talk to ten firms that have a seat to fill, one of them may go the consulting route, even though that wasn’t their original thought.

Talk to recruiters. It may sounds at odds with what I said above, but it can be very valuable. Recruiters have their finger on the pulse. Even if their not physicians, they can measure the pulse. So too they may not know redshift from Oracle, but they’re hearing what the industry is looking for. They have a great perspective to share.

Go to non-peer events. Expand your horizons. Surprise yourself with who might attend other events. Tell your story. In the process, ask others where they spend time.

Ping all the people. Yes keep in touch with folks. You may create a newsletter to help with this. See below.

Keep the pipeline warm. Once you get a gig, you may quickly give up the socializing because you just want to do the work. But this will fail in the long term. You have to like the socializing and keep doing it. Even while you have an engagement or two going.

Always *GET* cards. Giving them is fine, but be sure to get the contact of the other person. 99% will not followup. That’s your job!

Related: When clients don’t pay

3. Build your reputation

When people search your name, they should find you. On social networks like Linkedin, github, twitter, google plus, Slideshare, StackOverflow etc. Create profiles on all of these. Link them back to your professional site.

You *do* have a professional site right? If not go get a domain right now. devopsguru.io, backenddeveloper.guru, whatever! The domain doesn’t matter that much, most traffic will come from google, and it won’t be going to your homepage anyway.

Speak at non-peer events & conferences. Lunch & learns. Co-working spaces, incubators. These all have events, they’re all looking for experts. You may also apply to CFP’s regularly. Hey you might even get some conference passes out of it!

As I also mentioned above, a newsletter is also a good idea. Add every single person you meet in your professional context. It gives you something else to talk about as you are socializing. ๐Ÿ™‚

Related: Why i ask for a deposit

4. Positioning

This one is counterintuitive. Why can’t I just do the thing I love.

Well sure maybe you can. But finding an underserved niche is a fast track to success. To my mind it’s crucial. So find out what is in demand. I know you’ve been talking to recruiters, right?

So yes pay attention to the wind. And pivot as necessary. Keep reading and stay up to date on new tech.

Related: Can progress reports help your engagements succeed?

5. What you might find

Don’t expect to get in at large companies like google & facebook, or with defense contractors. There’s a terrible amount of bearocracy, and you would need a larger team to become an approved vendor. Also many of these larger well organized firms already have tons of talent.

You’re better suited to less organized, or newer companies. Because you want to be able to raise the bar for them. Better you start where the bar is a bit lower.

Examples…

o small early stage startups

These folks have some money, but they are still small so they may not need a fullsize engineering organization. They also need things done yesterday. So they are ripe with opportunities.

o medium size startups

Same as above. But they may be having trouble finding your skills. Because you’ve found that niche, right?

o greenfield

Startups building an mvp, where the skies the limit. You have the opportunity to build out the first gen. Go for it!

o second generation & legacy

Once a startup has seen it’s first round of developers leave, they may be in a spot, where the business is great, but the product needs lifting. You’re looking at a quote-unquote legacy application, and you need to use your skills to tune, troubleshoot, and identify technical debt.

Related: Why do people leave consulting?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All CTO/CIO Devops Scalability

How organizations can move faster with devops – a16z Sonal Chokshi interviews Nicole Forsgren & Jez Humble

via GIPHY

We hear a lot about devops these days, and the promise is temendous. It originally evolved out of Agile operations. But how to get those benefits at *my* organization?

Join 38,000 others and follow Sean Hull on twitter @hullsean.

How do we become a high performing organization, to move faster and build more secure and resilient systems? That’s the $64,000 question!

A16Z strikes again! Andreeson Horowitz’s epic podcast hosts world class guests around all sorts of startup & new technology topics. This week they interview Jez Humble and Nicole Forsgren. They run Dora which is DevOps Research and Assessment, which shows organizations just how to get the advantages of devops in the real world.

Technology does not drive organizational performance

Check out section 16:04 in the podcast…


“the point of distinction comes from how you tie process and culture together technology through devops”

It’s the classic Amazon model. They’re running hundreds of experiments in production at any one time!

Related: The 4 letter word dividing dev and ops

Day one is short, day two is long

The first interesting quote that caught my attention was at 4:40…


“Day one is when we create all of these systems. Day two is when we deploy to production. We have to deploy and maintain forever and ever and ever. We hope that day two is really long.”

As a long time op, this really really resonates for me. Brownfield deployments, which have already seen a wave of developers finish, and leave, and trying to manage that. Not easy!

Related: Why generalists are better at scaling the web

Mainframes of Kubernetes?

What about tooling? Is that important? Here’s what Jez has to say. Jump to 29:30…


“Implementing those technologies does *not* give you those outcomes. You can achieve those results with Mainframes. Equally you can use Kubernetes, Docker and microservices and not achieve those outcomes.”

Related: Is Amazon too big to fail?

Reducing Friction

Fast forward to timecode 28:45…


“Conways Law: Organizations which design systems are constrained to produce designs that are copies of the communication structures of these organizations.”

ie your software code looks like the shape of organization itself, and how we communicate. Super interesting. ๐Ÿ™‚

Related: 6 devops interview questions

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Cloud Computing Devops

How to setup an Amazon ECS cluster with Terraform

via GIPHY

ECS is Amazon’s Elastic Container Service. That’s greek for how you get docker containers running in the cloud. It’s sort of like Kubernetes without all the bells and whistles.

It takes a bit of getting used to, but This terraform how to, should get you moving. You need an EC2 host to run your containers on, you need a task that defines your container image & resources, and lastly a service which tells ECS which cluster to run on and registers with ALB if you have one.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

For each of these sections, create files: roles.tf, instance.tf, task.tf, service.tf, alb.tf. What I would recommend is create the first file roles.tf, then do:


$ terraform init
$ terraform plan
$ terraform apply

Then move on to instance.tf and do the terraform apply. One by one, next task, then service then finally alb. This way if you encounter errors, you can troubleshoot minimally, rather than digging through five files for the culprit.

This howto also requires a vpc. Terraform has a very good community vpc which will get you going in no time.

I recommend deploying in the public subnets for your first run, to avoid complexity of jump box, and private IPs for ecs instance etc.

Good luck!

May the terraform force be with you!

First setup roles

Roles are a really brilliant part of the aws stack. Inside of IAM or identity access and management, you can create roles. These are collections of privileges. I’m allowed to use this S3 bucket, but not others. I can use EC2, but not Athena. And so forth. There are some special policies already created just for ECS and you’ll need roles to use them.

These roles will be applied at the instance level, so your ecs host doesn’t have to pass credentials around. Clean. Secure. Smart!


resource "aws_iam_role" "ecs-instance-role" {
name = "ecs-instance-role"
path = "/"
assume_role_policy = "${data.aws_iam_policy_document.ecs-instance-policy.json}"
}

data "aws_iam_policy_document" "ecs-instance-policy" {
statement {
actions = ["sts:AssumeRole"]

principals {
type = "Service"
identifiers = ["ec2.amazonaws.com"]
}
}
}

resource "aws_iam_role_policy_attachment" "ecs-instance-role-attachment" {
role = "${aws_iam_role.ecs-instance-role.name}"
policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role"
}

resource "aws_iam_instance_profile" "ecs-instance-profile" {
name = "ecs-instance-profile"
path = "/"
role = "${aws_iam_role.ecs-instance-role.id}"
provisioner "local-exec" {
command = "sleep 60"
}
}

resource "aws_iam_role" "ecs-service-role" {
name = "ecs-service-role"
path = "/"
assume_role_policy = "${data.aws_iam_policy_document.ecs-service-policy.json}"
}

resource "aws_iam_role_policy_attachment" "ecs-service-role-attachment" {
role = "${aws_iam_role.ecs-service-role.name}"
policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceRole"
}

data "aws_iam_policy_document" "ecs-service-policy" {
statement {
actions = ["sts:AssumeRole"]

principals {
type = "Service"
identifiers = ["ecs.amazonaws.com"]
}
}
}

Related: 30 questions to ask a serverless fanboy

Setup your ecs host instance

Next you need EC2 instances on which to run your docker containers. Turns out AWS has already built AMIs just for this purpose. They call them ECS Optimized Images. There is one unique AMI id for each region. So be sure you’re using the right one for your setup.

The other thing that your instance needs to do is echo the cluster name to /etc/ecs/ecs.config. You can see us doing that in the user_data script section.

Lastly we’re configuring our instance inside of an auto-scaling group. That’s so we can easily add more instances dynamically to scale up or down as necessary.


#
# the ECS optimized AMI's change by region. You can lookup the AMI here:
# https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
#
# us-east-1 ami-aff65ad2
# us-east-2 ami-64300001
# us-west-1 ami-69677709
# us-west-2 ami-40ddb938
#

#
# need to add security group config
# so that we can ssh into an ecs host from bastion box
#

resource "aws_launch_configuration" "ecs-launch-configuration" {
name = "ecs-launch-configuration"
image_id = "ami-aff65ad2"
instance_type = "t2.medium"
iam_instance_profile = "${aws_iam_instance_profile.ecs-instance-profile.id}"

root_block_device {
volume_type = "standard"
volume_size = 100
delete_on_termination = true
}

lifecycle {
create_before_destroy = true
}

associate_public_ip_address = "false"
key_name = "testone"

#
# register the cluster name with ecs-agent which will in turn coord
# with the AWS api about the cluster
#
user_data = <> /etc/ecs/ecs.config
EOF
}

#
# need an ASG so we can easily add more ecs host nodes as necessary
#
resource "aws_autoscaling_group" "ecs-autoscaling-group" {
name = "ecs-autoscaling-group"
max_size = "2"
min_size = "1"
desired_capacity = "1"

# vpc_zone_identifier = ["subnet-41395d29"]
vpc_zone_identifier = ["${module.new-vpc.private_subnets}"]
launch_configuration = "${aws_launch_configuration.ecs-launch-configuration.name}"
health_check_type = "ELB"

tag {
key = "Name"
value = "ECS-myecscluster"
propagate_at_launch = true
}
}

resource "aws_ecs_cluster" "test-ecs-cluster" {
name = "myecscluster"
}

Related: Is there a serious skills shortage in the devops space?

Setup your task definition

The third thing you need is a task. This one will spinup a generic nginx container. It’s a nice way to demonstrate things. For your real world usage, you’ll replace the image line with a docker image that you’ve pushed to ECR. I’ll leave that as an exercise. Once you have the cluster working, you should get the hang of things.

Note the portmappings, memory and CPU. All things you might expect to see in a docker-compose.yml file. So these tasks should look somewhat familiar.


data "aws_ecs_task_definition" "test" {
task_definition = "${aws_ecs_task_definition.test.family}"
depends_on = ["aws_ecs_task_definition.test"]
}

resource "aws_ecs_task_definition" "test" {
family = "test-family"

container_definitions = < < DEFINITION [ { "name": "nginx", "image": "nginx:latest", "memory": 128, "cpu": 128, "essential": true, "portMappings": [ { "hostPort": 0, "containerPort": 80, "protocol": "tcp" } ] } ] DEFINITION }

Related: Is AWS too complex for small dev teams?

Setup your service definition

The fourth thing you need to do is setup a service. The task above is a manifest, describing your containers needs. It is now registered, but nothing is running.

When you apply the service your container will startup. What I like to do is, ssh into the ecs host box. Get comfortable. Then issue $ watch "docker ps". This will repeatedly run "docker ps" every two seconds. Once you have that running, do your terraform apply for this service piece.

As you watch, you'll see ECS start your container, and it will suddenly appear in your watch terminal. It will first show "starting". Once it is started, it should say "healthy".


resource "aws_ecs_service" "test-ecs-service" {
name = "test-vz-service"
cluster = "${aws_ecs_cluster.test-ecs-cluster.id}"
task_definition = "${aws_ecs_task_definition.test.family}:${max("${aws_ecs_task_definition.test.revision}", "${data.aws_ecs_task_definition.test.revision}")}"
desired_count = 1
iam_role = "${aws_iam_role.ecs-service-role.name}"

load_balancer {
target_group_arn = "${aws_alb_target_group.test.id}"
container_name = "nginx"
container_port = "80"
}

depends_on = [
# "aws_iam_role_policy.ecs-service",
"aws_alb_listener.front_end",
]
}

Related: Does AWS have a dirty secret?

Setup your application load balancer

The above will all work by itself. However for a real-world use case, you'll want to have an ALB. This one has only a simple HTTP port 80 listener. These are much simpler than setting up 443 for SSL, so baby steps first.

Once you have the ALB going, new containers will register with the target group, to let the alb know about them. In "docker ps" you'll notice they are running on a lot of high numbered ports. These are the hostPorts which are dynamically assigned. The container ports are all 80.


#
#
resource "aws_alb_target_group" "test" {
name = "my-alb-group"
port = 80
protocol = "HTTP"
vpc_id = "${module.new-vpc.vpc_id}"
}

resource "aws_alb" "main" {
name = "my-alb-ecs"
subnets = ["${module.new-vpc.public_subnets}"]
security_groups = ["${module.new-vpc.default_security_group_id}"]
}

resource "aws_alb_listener" "front_end" {
load_balancer_arn = "${aws_alb.main.id}"
port = "80"
protocol = "HTTP"

default_action {
target_group_arn = "${aws_alb_target_group.test.id}"
type = "forward"
}
}

You will also want to add a domain name, so that as your infra changes, and if you rebuild your ALB, the name of your application doesn't vary. Route53 will adjust as terraform changes are applied. Pretty cool.


resource "aws_route53_record" "myapp" {
zone_id = "${aws_route53_zone.primary.zone_id}"
name = "myapp.mydomain.com"
type = "CNAME"
ttl = "60"
records = ["${aws_alb.main.dns_name}"]

depends_on = ["aws_alb.main"]
}

Related: How to deploy on EC2 with vagrant

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don't work with recruiters