Categories
All Cloud Computing CTO/CIO

Why is there a company whose only purpose is to help me with my AWS bill?

via GIPHY

I know everyone is talking about the pandemic at the moment, I thought I would sidestep the topic, and continue to discuss what I know best. Which is public cloud!

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

Of late, I see more and more discussions on CTO forums, and in the news on surprise AWS bills. Did you hear what happened NASA’s cloud deployment fail?

So I thought I’d provide some history, and a few ideas…

1. Oracle days

Believe it or not this has happened before. In the days when I did a lot of Oracle work, I remember it was terrible how tough their licensing was. And companies were pretty much hamstrung because they needed the technology to run their business.

Given the demand, new firms like Miro Consulting stepped in to help. Their business is specifically built to help customers with out-of-control Oracle bills.

Read: How to hire a developer that doesn’t suck

2. Repeating refrain

What’s this got to do with Amazon Web Services you say?

Just today I discovered a firm that promises to help you lower your aws bill by 20-40%.

Promises aside, if there is a business doing this, there must be money to be made in it. So that speaks to a sizeable market opportunity.

Related: When you have to take the fall

3. AWS has a webinar on the topic

Hey if you’re thinking you can manage it yourself, why not look to AWS for assistance on lowering your bill.

Something tells me there’s a conflict of interest there, but I digress.

Point is with this topic becoming of growing interest, I think you’ll see more businesses stepping into this niche.

Related: How do I migrate my skills to the cloud?

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 Startups

I’m building a startup. What should I watch out for?

via GIPHY

I’ve worked with close to 200 startups over the years. So I’ve seen a lot of stuff. Some of the get-rich-quick managed to get broke even quicker. And others saw great engineers leave behind a clunky maze of an architecture with little or no documtation.

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

Here are some thoughts on what to be mindful of…

1. Keep the stack simple

Are you asking yourself questions like these:

o if we build x,y,z it will save us time later
o we need kubernetes because everyone is using it
o let’s deploy on Amazon’s Cloud, everyone is there

If so you may have sidestepped keeping the stack simple. If you are building a proof of concept, mvp, chances are you do not need to build all the bells and whistles.

Relentlessly apply the discipline to keep things simple.

Read: Are pioneers and process people different breeds?

2. Use boring technology

You may be tempted to use some exotic new language. I know this new framework solves all the problems that have come before. No!

Let someone else live on the bleeding edge. I’m not suggesting to use COBOL, though there is still a surprising amount of that still around. What I’m saying is 5 year old tech is *not* legacy.

Not sure? Do a quick search on a job site for the language or technology. How many candidates do you get? If they are rarer you will pay more. And replacing your genius developer will be even harder.

But boring technology is not just about finding talent. It means many of the problems have already been solved. This is huge. There are proven ways to implement with the tried and true.

Related: Why is Martin Weiner special?

3. Beware of sharks in the water

Sharks can come in many forms. Investors that want to take 50%, a google or an Amazon that could rearchitect your solution in a week. These are real and present dangers.

Let’s not forget overspending on co-working spaces, and hidden costs around benefits, and surprising fees on your data or aws bill.

Related: How can 1% of something equal nothing?

4. Outsourcing – trust but verify

You may be able to hire one or two devs locally in new york, but if you need a larger team, you’ll likely look to outsourcing. There are tons of talented and brilliant engineers worldwide. So it makes sense to leverage this.

Beware though of handing all control to a team outside our shores. That’s because if you stumble into a legal trouble, you cannot use legal methods to resolve them. Some examples…

o what if you lost your aws keys and the outsource team holds you hostage?
o what if you are hacked, and the outsource team abandons the project?
o what if the outsource team tries to steal your IP?

I’m not suggesting here that outsource teams are any more likely to do these things than some firm locally. I think these events are rare in business. But if they happen local you can use the levers of the justice system to resolve. Remote may not lend to that.

Related: The art of resistance – when you have to be the bad guy

5. Relentlessly manage time

Your time is going to be short, and you’re trying to do the impossible. Use the tech wisely:

o use monitoring systems to alert you – no need to manually check things
o beware of slack and email – as they can destroy productivity
o automate where you can see real benefits
o keep the architecture simple!
o network for hiring people

Related: Is maintenance a forgotten art?

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

What can we learn from NASA’s AWS fail?

via GIPHY

I was just reading the Register, which is sort of the UK’s version of Slashdot, and they had a jaw dropping title. NASA moved 247 petabytes into AWS and then later learned about EGRESS costs

OMG! Face palm. Wow.

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

To say this is a disaster is an understatement. Could it have been prevented? Not likely by 100% strategic thinking. I believe a certain amount of real-world testing & prototyping is the only way.

Here are my thoughts…

1. Expect hidden costs

Everytime I check there are more AWS services. Just now I did some googling, and the number stands at 170. Not only is it tough to keep up with all of those, but the offerings are constantly evolving, getting new features and so forth. That means the pricing and costs are evolving too.

All this means an infinitely complex web of interconnecting pieces, so it is near impossible to predict prices in advance. The solution? Prototype.

And this would have helped save NASA. Because you would build, feature test and load test too. In all of that would have come a small estimate of cost which would include EGRESS costs.

There are no guarantees in this game, but it is surely getting complicated.

Read: How can 1% of something equal nothing?

2. Vendor lock-in is not dead

With the receding of some of the big old world vendors like Oracle, many have forgotten the shark like tactics they used with startup companies.

The model was something like this. Send in the big guns, nicely dressed to get you on board. Finesse the sale. Offer deep discounts, and get the customer on Oracle. After a year, maybe too, start squeezing. You’d be surprised how much blood comes out of diamonds.

These days we feel more free to port our applications to different cloud vendors. Even if mostly everybody is on Amazon already. But this NASA story really highlights the great organizational cost to migrate to the cloud. You architect your application, you do cost planning, and so on. So once you’re there, it’s hard to unravel.

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

3. New possible hacking vector

Since costs are tied to usage in the public cloud, this could have implications for hacking. If a bad actor wants to cause you harm, then can now just use your service more.

Don’t like company A? Write some bots to access them from obscure locations, and ramp up those egress costs. With all the complexity of the cloud, are most firms monitoring for this sort of thing? I don’t see it in my engagements.

Something similar happened to me. I wrote: when mailchimp fraudulently charged my credit card. It really happened. Do I think it was intentional? You’ll have to read the article to get my 360 degree take on it.

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 Devops Disaster Recovery Scalability

Do simpler systems fail better?

via GIPHY

I was recently reading Greg Kogan’s blog Simple Systems have less downtime.

It really caught my attention.

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

As a professional services consultant over the years, I’ve worked with almost 200 firms. And many of those required unraveling of complex systems. And systems that were no longer well understood after the first wave of builders have long since gone.

So this topic resonates strongly for me.

I believe if firms adopted these advice, I would have a lot less work over the years. Seriously.

1. Redundancy

Redundancy means backup systems. If your laptop fails, do you have a second one with all your up-to-date data? If us-east-1 fails, do you have a backup or live copy of your database in another region?

Redundancy isn’t just backup systems, it is backup people. If Jane who manages Salesforce gets in an accident, what will the business do to support the sales teams? If a system gets hacked and compromised, how can you restore the most recent data?

Complex systems fail in surprising ways. Having a plan B, and plan C, and for really essential services and plan D will save the day.

Take Greg’s example of a container ship:
o if the automatic system fails you can steer the thing manually. Wow!
o if other electronics fail, you can control the damn rudder by hand!

Incredible to think a ship that big is basically a giant sailboat when you disengaged the powered systems. That is truly a lesson for all of us startup engineers.

Read: How can 1% of something equal nothing?

2. Overlapping skillsets

If you only have one guy who knows how to use the database platform, that’s a problem. If you have only one woman who knows how to program in Rust, that’s a problem. If there’s only one person who knows how the reporting system works, and can make changes, that’s a problem.

Better to have overlapping job roles and skillsets. If you have a chance to adopt a new technology, make sure it’s rock solid one that is mainstream, and easy to hire for.

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

3. Beware of technical debt

We’ve all heard the reasons.


o We don’t have the luxury to fix that now.

o We can’t afford the downtime.

o We have pressing features to ship.

But as technical debt piles on, so does complexity. And you’ll quickly end up end up carrying a larger burden than you realized.

As advocated by Kogan, rip and replace is often a more serious solution, and better for the firm. Yes you’ll have some downtime. Yes you’ll redirect team members temporarily. But you’ll solve the real problem, and will bring more simplicity to your architecture.

What’s more the pain of paying down the debt will make you think twice about borrowing in the future!

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 Blogging

What are the top posts of the past year?

via GIPHY

I dug through google analytics to see which posts have been the most popular.

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

In the past year, the following posts stuck out…

1. Tech

Bye Bye Kubernetes

How can we keep cloud architectures simple?

Are shared databases back in vogue?

What Matt Ranney learned scaling Uber

What does Devops mean?

How crazy can Kubernetes get?

When should I use ansible vs packer vs terraform?

Read: Are pioneers and process people different breeds?

2. Process

How I use 5 daily habits to stay on track

What happens when you offer consulting advice outside your pay grade?

What do senior engineers do differently?

What tools are devops engineers using today?

Do you fear you are an imposter?

What dothe best engineers do better?

Related: What happens when a bartender doesn’t get the job and files a lawsuit instead?

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