Categories
All Consulting CTO/CIO Devops Hiring

Should I join this new startup Delicious Data?

via GIPHY

I’ve been asked this before by folks.

Hey, you know technology, what stock picks would you recommend?

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

It’s a tough question, with a lot of intangibles. It’s no wonder people ask friends for advice. You have to think about what matters to you? Your free time? Your income? Your time to commute? What about the team you’re working with? Or what your job contributes to the world?

Many of those I can’t quantify for you. What you can quantify money, so it’s worth doing that!

1. What are their prospects for success?

When asked about the chances of a companies success, knowing the industry may be one small part. You also have to know how many competitors they have, and where they are along in the process. And it’s not just developing technology, but team dynamics that are huge. From what I hear VCs hire more for team than for idea.

What factors outside domain expertise come into play? Lots! The weather, financial markets, or the big guys like google or amazon coming into the market. They may not buy you, they may just replicate your idea. Then where are you?

Read: How to hack job search the smart way

2. How can I apply mathematics to money?

My answer is always the same, go for the S&P 500. If the S&P beats 90% of all stocks, then nine out of ten times you will win this way. That’s it, calculation done.

Yeah but how does that pertain to joining a startup?

How indeed. I still say invest in the index, not in one pony. So use that advice as you will.

Gambling on one company is something for gamblers. If you want to become a vc, that’s a different question. In that case you would do a lot of due diligence on team and idea, to be sure you’re putting your money in a smart place.

Can’t I do that as an employee? Yes sure, but the intangibles remain strong.

How can 1% of something equal nothing?.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. How does all this help me?

It leaves out the intangibles. Don’t count paper as part of your compensation package. If money is a key factor, divide the number of hours per year by your salary plus real benefits – health insurance and so forth – to come up with a real number. Compare that to other jobs.

The heck with these finance jobs that pay $200k and offer a $50k bonus, but ask you to work 90-100 hours per week. Why not get two $180k/yr jobs at 45 hours per week? You see the logic right?

And what else? Of course if you’re going to be commuting in to an office everyday, and joining the family, you want to have great coworkers. So make sure you like the place where you’re working. I don’t know how much this is worth to you, but I would say it’s quite valuable!

Related: What to do when prospects mislead you?

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 Security

Does Amazon’s security work well for startups?

via GIPHY

I was sifting through my project & progress reports from former clients today. Something struck me loud and clear. It seems 4 out of 5 of them don’t implement VPC best practices.

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

Which begs the question again and again, is the service just too damn complicated? I wrote about this topic before… Is aws a bit too complex for most or at least smaller dev teams?

1. No private subnets

What are those you ask? I really hope you’re not asking that.

The best practices way to deploy on amazon is using a vpc. This provides a logical grouping. You could have a dev, stage and prod vpc, and perhaps a utility one for other more permanent services.

Within that VPC, you want to have everything deployed in one or more private subnets. These are each mapped to a specific AZ in that region. The AZ mapps to a physical datacenter, a single building within that region. These private subnets have *NO route to the internet*.

How do you reach resources in the private subnet? You must be coming from the public subnet deployed within that same VPC. All the routing rules enforce this. The two types of resources that would be deployed in public subnet: load balancer for 80/443 traffic, and a jump or bastion box for ssh.

Read: How can 1% of something equal nothing?

2. Security groups with all ports open

Another thing that I see more often than you might guess is all ports open by some wildcard rule. *BAD*. We all know it’s bad, but it happens. And then it gets forgotten. We see developers doing it as a temporary fix to get something working and forget to later plug up the hole.

Even for security groups that don’t have this problem, they often allow port 22 from anywhere on the internet (0.0.0.0). This is unnecessary and rather reckless. Everyone should be coming from known source IPs. This can be an office network, or it can be some other trusted server on the internet. Or a block of IPs that you’ll always have assigned.

And of course don’t have your database port open. MySQL and Postgres don’t have particularly great protections here.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. No flowlogs enabled

Flowlogs allow you to log things at the packet level. Want to know about failed ssh attempts? Log that. What to know about other ports? Log that too.

If you are funneling all your connections through a jump box, then you can just enable flowlogs then you can configure your vpc flowlogs monitoring just for that box itself. You may also want to watch what’s happening with the load balancer too.

Flowlogs work at the network interface layer of your VPC, so you’ll need to understand VPCs in depth.

Related: What mistakes did you make when starting as a consultant?

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 Consulting CTO/CIO Devops Software Development

Do you fear you are an imposter? Join the club

via GIPHY

I was reading another delicious hacker news thread, this time on a psychology question. How do you work with the fear of your own incompetence?

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

It’s a great question. I’ve had this suspicion for years, and it was only after stumbling on psychology books that I even knew it was a thing.

So how *do* you manage this fear?

1. Demonstrate that it is a fear

Fear is a funny thing. It can color reality. You may not even realize it’s happening. When it comes to imposter syndrome, prove yourself wrong. Do the work, and then step back and show yourself the evidence.

You’re a logical rational engineer, so you should be able to weigh the evidence, and see that you made a mistake.

Doing good work is not about perfectionism. It is about knowing you can execute, and delivering quality. That doesn’t not mean there are no imperfections. That means good enough. That means equal to or better than the team you’re working in.

That means you’re improving the bottom line for the firm you’re part of. Help them deliver new features, new code, new product. And help other team members do the same. That’s the name of the game.

Read: How can 1% of something equal nothing?

2. Look at your history

Whenever I have this feeling, I look at my own history. Then it makes me sorta chuckle. I have a list of twenty companies that I worked for recently, and they’ve all been really happy with my work.

How do I know I did good work? They paid me handsomely, paid me on time, and then recommended me to other colleagues.

That’s how I know I’m not an imposter. Am I perfect? Nope. Do I know everything? Nope? But I do good work, and I take ownership, admit when I’m wrong, and play well with others.

If you want to stand out, take a look at these two pieces:

Check out: What do the best engineers do better?

And this: How to think like a senior engineer

Those will help you on your way…

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. Realize your perfectionism

I think a lot of engineers or bright people have this problem. They want everything to be perfect. They want to produce documents without spelling errors, and code without bugs. They want to deliver everything on time perfectly every time. And they want to feel they know everything.

But it doesn’t play to your benefit. People resent this type of thinking, and it’s unhealthy besides. Take a deep breath, realize we’re all working towards the same goal, and keep your eye on the ball. That means have a sense of humor. You’re probably *way* harder on yourself then others will ever be.

Related: What mistakes did you make when starting as a consultant?

4. Be easier on yourself and easier on others

As you begin to be “easier” on yourself, hopefully you’ll also be a little bit easier on others. Be patient with mistakes. Understand that people have a lot going on in their life. Notice that they are trying.

Sure even after you gain a sense of humor, there will be some people who are not trying, who don’t care or who are really incompetent. But have your default position be patience, and give them and yourself the benefit of the doubt.

Usually if said person is really that bad, others will also complain and the problem will come to management’s attention. It is their job, after all to manage the team as a whole, and keep it productive.

Have fun!

Related: Why did mailchimp fraudulently charge my credit card?

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 Consulting CTO/CIO Security

How do we secure an existing aws hosted application?

via GIPHY

What if you don’t have the luxury of a greenfield. You are looking at an already built application, and asking yourself, how do I secure this?

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

One can think of it as a giant labyrinth, with many turns and many paths. Some of those paths have not had light shining in them for some time. So you’ll need to be cautious, thorough, and vigilant.

Here are some notes on where to start.

1. Scanning – code

One area you’ll need to dig into is the application code itself. If you don’t have the luxury to push new code, you’ll need to verify what version is deployed, and scan the repository for keys or passwords. You can also scan on the server itself. Better to double your efforts.

Read: What do the best engineers do better?

2. Scanning – network

Your VPC is obviously your first layer of defense. Scan the routing table policies, to make sure there aren’t open ports or whitelisted IPs.

Do the same sort of review for security groups, as those are an alternative method for configuring access to servers.

AWS has a service called Flowlogs, which can be enabled. These give you detailed network layer logging, which you can then scan for trouble.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. Scanning – IAM, keys & console

Your existing devs probably have keys to some or all of the EC2 boxes. If you don’t want to relaunch all of these boxes with new keys, or don’t have the luxury to do that, you’ll need to lock down the security groups, whitelisted IPs and VPC routing rules.

You’ll also need to carefully review IAM roles & policies. Amazon Inspector may be a useful tool to scan your environment, and find glaring holes and enforce best practices. But you’ll also want to do your own scanning both automated and manually eyeballing the accounts.

You’ll also want to lock down console access, especially the root account, and any others that have adminstrator privileges. Enable password policies and password rotation, as well as multi-factor authentication. There is also a nice toggle for “alert on login”. You certainly want to know about those!

Related: What mistakes did you make when starting as a consultant?

4. Scanning – services

Review all of the AWS services that are deployed. Ask yourself some of these questions:

o which regions & availability zones am I deployed in?
o what elastic IPs do I have configured where?
o what IAM roles & policies do I have created?
o what databases, API gateways & S3 buckets are configured
o etc…

Cloudtrail can be a great help here as it can log all sorts of useful information. You can then scan those logs for problems.

Related: Why did mailchimp fraudulently charge my credit card?

5. Rebuilding

The scanning approach can work, but there is a strong need to be thorough. If you miss one whitelisted IP or existing ssh key, you can leave the whole network open to a crafty intruder.

Another option is to rebuild the whole application. This gives you the time to:

o automate the whole stack with terraform
o test that everything is working
o plan for failover
o ensure that every bucket is secure with lifecycle policies enabled
o ensure that every EBS volume is encrypted
o enabled cloudtrail, cloudwatch etc

o potentially setup in a *brand new* aws account, for even more confidence
o backup all the pieces of the application as you go

Read: Did Disney+ have to fail?

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