Amazon Cloud Hosting: Technisch applicatiebeheerder overbodig of toch niet?

De populariteit van grote cloud omgevingen zoals EC2 van Amazon hebben ontwikkelaars over de hele wereld de tools gegeven om het technisch applicatiebeheer zelf te doen. Is dit wel terecht en wat zou een betere rolverdeling zijn? 

De Amazon Cloud werkt via een API
De industrie was gewend te werken via de driehoek van opdrachtgever, applicatiebouwer en hostingpartij. Als er meer capaciteit nodig was dan zorgde de hostingpartij daar voor, vaak op basis van specificaties van de applicatiebouwer.  De hostingpartner ging dan bij wijze van spreken een fysieke server uitbreiden met meer geheugen. Of in het geval van virtualisatie ging men meer geheugen toewijzen in de virtualisatielaag. Vanaf het verzoek tot de invulling zitten er dus wel verschillende mensenhanden aan te werken.

De Amazon Cloud wordt aangestuurd via een API (application programming interface) waardoor de ontwikkelaar vanuit haar eigen applicatie de hostingomgeving kan aanpassen. Zo kan er bijvoorbeeld opgeschaald worden binnen minuten en nog geheel automatisch ook. Om dit mogelijk te maken moeten dus de interne processen van Amazon volledig geautomatiseerd zijn. Maar ook de opdracht van de klant wordt dankzij de API automatisch verwerkt.

De API werkt op twee niveaus
Op twee manieren geeft een hosting API gemak aan de ontwikkelaar. Ten eerste kan bij het opzetten van een nieuwe omgeving simpelweg opdracht gegeven worden om die omgeving op te starten. En in een mum van een tijd draait de serveromgeving. Daarnaast is bij een bestaande omgeving het dus mogelijk om allerlei wijzigingen door te voeren op een geautomatiseerde manier.

Dit is van belang goed te beseffen. De softwareontwikkelaar kan dus de omgevingen opstarten en daarna ook uitbreiden en wijzigen. Typisch taken die voorheen altijd door de hostingpartner (de technisch applicatiebeheerder) werden uitgevoerd. Het is dus logisch dat de trend is ontstaan dat softwareontwikkelaars zelf de hosting regelen via een partij als Amazon.

Adder onder het gras?
Het gemak van het neerzetten van een hostingomgeving in een cloud geven duizenden softwareontwikkelaars, en hun klanten, het onterechte gevoel dat alles dan onder controle is. De waarheid is namelijk dat bij technische problemen van Amazon regelmatig websites down gingen. In de meeste gevallen was dit niet nodig geweest als de Amazon infrastructuur anders was ingezet. Het ontwerpen van een redundante infrastructuur op Amazon EC2 is een vak apart. En een heel ander vak dan software ontwikkelen. De klassieke scheiding tussen development en beheer is er dus nog steeds. Een beheerder moet altijd conservatief zijn en vooral stabiliteit willen. Een ontwikkelaar wil nieuwe features bouwen en innovatief zijn en daarom is het goed dat verschillende mensen, verschillende rollen hebben.

Nieuwe klantvragen.
Een nieuwe klantvraag is aan het ontstaan. Namelijk: “Wij hebben omgevingen bij Amazon, maar wie kan het technische applicatiebeheer professioneel uitvoeren?”.  De volgende klantvraag die logischerwijs zal volgen is: “Nu we een beheerder hebben die alles van Amazon weet, kan die dan ons ook helpen met het inrichten van de volgende Amazon omgeving zodat we beter beschermd zijn tegen technische incidenten?”.

Conclusie
De early adopters die zelf de hosting doen bij Amazon hebben de uitdagingen inmiddels wel een keer meegemaakt. Hierdoor zal de trend van “ik kan het zelf” snel weer terugvallen naar een meer gezonde verdeling waarbij bedrijven “doen waar ze goed in zijn”. Hierbij gaat Cloud hosting zeker een rol spelen maar niet op een manier dat hosting niets meer is dan op een knopje drukken in een control panel. Dat kan misschien voor een eenvoudige website. Maar voor bedrijfskritische applicaties waar security en performance het meest belangrijk zijn daar zal de noodzaak voor een partner met de juiste kennis en middelen alleen maar toenemen.