IT Infrastructure has an image problem. It is not "sexy".
It's not winning the technology market place for talent. Many candidates I've interviewed want to sharpen their tools for Android, iOS, Big Data or RESTful Cloud APIs.
Problem is: APIs, distributed data pools, REST handlers and scale for 100,000 users all needs to go somewhere.
In many cases, people who have smart new ideas which answer the needs of 100K swinging, social-media coolkats also have a pretty good idea they need a bit of web, database and a server or two to boot up. Perhaps they can avoid some of those with savvy use of some software-as-a-service or infrastructure-as-a-service.
It's also true if you're not 100% savvy, you can hit the web for a ton of free code and tutorials. Save yourself a couple thousand man-hours of effort to be up and running in weeks with enough infrastructure scaffolding to support your prototype.
OK If you've gotten this far and you've seen this, recognise your "core" business is your app. That's your business. The surrounding infrastructure and the people who run it are - at best - awesome talent contributing to every success. At worse - a direct cost of doing business that started the second you launched your first EC2 instance.
Whether you have funding or not, that infrastructure will challenge you. Yet, thoughtfully applied and organised it will enable you. Enable to you eat 100K users without failure, to side-step zone failures and resist incursion by the unruly mob.
Throughout my career I have played a number of roles in the technology infrastructure stack. I've played head-of-sorts in the .com startup and a voice among thousands in big Enterprise. I've seen what businesses with multi-billion IT spend their money on, what is acceptable and what they strive towards achieving as they support their money making businesses. I've seen how little of this appears necessary to startups, living fast and free, happy until the wheels fall off and focus shifts to a coffee stained finger-in-the-dyke sadness.
When building, you make hundreds of decisions during your day - the can-dos and the leave-for-laters. Frequently those leave-for-laters aren't left because you want to leave them, but because there are a few too many unknowns for right now, and you really must choose between those good task managers to remind you to invest time, later.
Hopefully you'll have plenty of these - it's all about being an entrepreneur. Not quite the business facing entrepreneur you started as, but the problem solving innovator who's bootstrapping their business infrastructure. If that is you, then I hope this book is useful.
Enterprise has solved these infrastructure problems that startups have. They have global, tactical teams. They have disaster recovery. They've revocation process around their people leaving them. They can control unaudited individuals accidentally purging all their live data. They have separation of duty, and zonal segregation of environments designed to prevent total outage if relatively minor binary bit falls in the wrong place...
Why should Startups solve all these problems over again. They have better things to focus on.
The central objective for this book is to cherry-pick from the wealth of experiences in large Enterprise to the benefit of Startup companies like yours. To provide a rapid deployment of sound architectural design, security best practice, performance and scalability, policy and process. The successful solutions ought to be light, nimble and cheap - the burden, and the metaload low.
I'm wondering about the delivery of Enterprise Computing for Startups. A book was the initial idea, and while I'm not a professional writer, I do write a lot and there lies a challenge. Perhaps - this - blog covers it, but enough meta debate: let's keep writing...
- Authentication, authorization and accounting - the who, how and why
- Core services - the chicken and the egg
- Deployment automation - do nothing twice
- Distributed data processing - speed and grid
- Global teamworking - don't mix metaphors
- Hierarchical structures - broadly, once
- Policy and process - a little goes a long way
- Separation of duty - less mistakes, easier to devops
- Sprint planning - once every two weeks
- Tickets and tasks - thanks for the memory
- Yum - startups like cake
The articles happened to fall out of my head in rough alphabetical order. Maybe it stays that way or not.
In true spirit of sharing, if this is something you'd like to see more of please drop me a line to my twitter.