↓ Archives ↓

Category → cloud

April 29th, 2010

Devops and Cloud

Whenever I give my Cloud security talk there's a slide in there talking about the most scary idea about Cloud and Security, the fact that Marketing people will build things on their own while IT, or any other departement isn't involved, and as we all know marketing people have no clue about security, it's not on their mind they won't even think about adding some sort of security to their application.

So IT isn't involved, Development isn't involved , and Operations isn't involved ...

Ages ago.. well.. about a decade I was working in those very marketing departments sitting there, writing code, hired by the marketeers, not by IT , the marketing PM did the talking to IT , we still had to go trough their IT department to get stuff deployed.

The marketing people had to deal with their impossible deadlines, a nationwide tv or radio campaign that was going to be launched , with a supporting website which meant that the website functionality needed to go live just before the first airing of the commercial. Obviously the website was lower priority than finding a famous voice or face to record the commercial with, so it became only late in the planning.. even more obvious was the fact that talking to IT about getting these new features deployed was even later on their planning .

Back then, part of my job was to smooth that process, my role was both creating the technical backend for the sites , putting them in production and doing the daily maintenance afterwards ...

Looking back at those days I realize the pains of both deployment and procurement, getting a new machine racked and then installed up to a bare os installations took up to 6 weeks, in a marketing driven world that meant that I'd often had to bypass the whole procurement process of expensive sunboxen and had to quickly deploy a linux box under my desk that could be used to move to production as plan B , and trust me .. we had to use plan B a lot ..

Letting nontechnical people deploy stuff in the cloud will only widen the gap, but getting involved early enough in the concept fase of a project with a good devops methodology/team in place will give the business people the opportunity to learn that things have changed , it doesn't take 6 weeks anymore to get an expensive Sun box racked and a Solaris instance installed after which a team of engineers needs to install an application server, then a different team needs to install the database etc .. these days it's a virtual machine instantiation and a couple of recipes ,in that way we can get manageable, reproducible and scalable deployments in no time.

Technorati Tags:Technorati Tags:
Share with Shareomatic! Share with Shareomatic!

Trackback URL for this post:

http://www.krisbuytaert.be/blog/trackback/1000
By Kris Buytaert • Posted in cloud, devops, history, marketing, opensource • Comments Off
November 5th, 2009

A long overdue report of DevopsDays

Here's how it started :

So I used to be a software developer, writing perl for the web, then C, then Java, then PHP, till I realized nobody ever configured my servers correctly and I changed trades becoming a system engineer, while teaching new developers the basics of their trade, whom grew into doing Infrastructure Architecture .. familiar story for much of the crowd at DevopsDays ... a crowd that wants to stopping the war between developers and system engineering , a crowd that wants to automate builds, integrate testing, deploy, deploy on very large scale, deploy in the cloud and much more.

So what do you get when you put together some of the experts on building software, organizing development teams , Agile geeks, Cloud infrastructure projects, and Automating guru's in 1 location for 2 days in Gent ? Exactly .. DevopsDays ..

The format was 2 days .. 3 kickass formal talks in the morning.. Open Space sessions in the afternoon. ... Friday featured talks on Non Functional Requirements, CucumberNagios and Monitoring in the Cloud with FlapJack and Building Agile Infrastructures with Puppet while discussing the James White Manifesto ..

which I had never heard of, but which apparently comes down to this

  1. == Rules ==
  2.  On Infrastructure
  3.  -----------------
  4.  There is one system, not a collection of systems.
  5.  The desired state of the system should be a known quantity.
  6.  The "known quantity" must be machine parseable.
  7.  The actual state of the system must self-correct to the desired state.
  8.  The only authoritative source for the actual state of the system is the system.
  9.  The entire system must be deployable using source media and text files.
  10.  
  11.  On Buying Software
  12.  -------------------
  13.  Keep the components in the infrastructure simple so it will be better understood.
  14.  All products must authenticate and authorize from external, configurable sources.
  15.  Use small tools that interoperate well, not one "do everything poorly" product.
  16.  Do not implement any product that no one in your organization has administered.
  17.  "Administered" does not mean saw it in a rigged demo, online or otherwise.
  18.  If you must deploy the product, hire someone who has implemented it before to do so.
  19.  
  20.  On Automation
  21.  -------------
  22.  Do not author any code you would not buy.
  23.  Do not implement any product that does not provide an API.
  24.  The provided API must have all functionality that the application provides.
  25.  The provided API must be tailored to more than one language and platform.
  26.  Source code counts as an API, and may be restricted to one language or platform.
  27.  The API must include functional examples and not requre someone to be an expert on the product to use.
  28.  Do not use any product with configurations that are not machine parseable and machine writeable.
  29.  All data stored in the product must be machine readable and writeable by applications other than the product itself.
  30.  Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.
  31.  
  32.  In general 
  33.  ----------
  34.  Keep the disparity in your architecture to an absolute minimum.
  35.  Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
  36.  Do not improve manual processes if you can automate them instead.
  37.  Do not buy software that requires bare-metal.
  38.  Manual data transfers and datastores maintained manually are to be avoided.

Much unlike the FAIL Manifesto

The openspaces tackled how to migrate from a totally unreproducable environment too a correctly bootstrapped infreaastructure, over the Ubuntu Enterprise Cloud , then dinner and off for beers to the Vooruit . The OpenQRM "crowd" stayed at my place so I didn't stay around too late ..

Saturday morning came early ... sadly I missed the first 10 minutes of a very interresting talk about Kanban in operations ... let's ee if we can convince some more people to try it out ...

The talk on Continuous integration, Build Pipelines and Continuous deployment was also really interresting with lots of stories from the real world.. . after the openqRM talk it was time again for OpenSpaces with e.g discussions on svn vs git and building a feature matrix of Cloud , with @botchagalupe, @openqrm and @maesjoch in the room and @diegomarino online .

Devopsdays ended too soon , with way to much interresting ideas to build on .. Let's hope we can all work them out !

Technorati Tags:Technorati Tags:
Share with Shareomatic! Share with Shareomatic!

Trackback URL for this post:

http://www.krisbuytaert.be/blog/trackback/955
By Kris Buytaert • Posted in IBBT, botchagalupe, cloud, dev, devops, devopsdays, eucalyptus, gent, openqr, opensource, ops, puppet • Comments Off