On 25 Oct 2010, at 10:05 , Ivo Ladage-van Doorn wrote: > Reading the discussions I have the following remarks/questions; > > -1- The extinction of the 'system administrator' role. > In his current job, Leon is responsible for server management from hardware > to software. He is responsible for the physical hardware and all 'basic' > software that runs on it, except the actual application that runs on the > server. His responsibility includes managing the database server, the web > server, the OS, the (J)VM, etc. etc. > In his new position however, Leon is responsible for ... for what? If Amazon > EC2 is used, he is probably only responsible for the Amazon contract to be > continued and paid each year. He doesn't do maintenance on the physical > hardware and he does not manage cluster nodes. He doesn't have shell access > to any machine. So in fact, his job ceased to exist.
I agree. There are basically three layers of things you can offer "as a service": 1. Infrastructure As A Service (IAAS). This is the lowest of the layers and basically you get guaranteed access to (virtualized) infrastructure with some pre-defined quality of service. You can look at EC-2 from Amazon as an implementation of IAAS, which means that in that case, Leon (the persona) is indeed out of a job. 2. Platform As A Service (PAAS). Builds on IAAS and offers higher level services (storage, authentication, webserver, ...). Again, you get to choose the required quality of service and the platform services are just there. In our case, some of the core Amdatu services can very well be offered "as a service" to software developers. 3. Software As A Service (SAAS). Builds on PAAS and offers the actual software. In our case that would, for example, be the Educa application. > I'm not saying this is a bad thing, but I wonder who takes over his tasks and > responsibilities in the new picture. Seems to me that these tasks are taken > over partially by Amazon (hardware, OS) and partially by Amdatu > (provisioning, fail over). In the light of the layers mentioned above, I see it's indeed partially the IAAS and the PAAS and SAAS (the latter two each offer provisioning and fail over for the services they provide). > But what if something bad happens? What if a database server goes down? What > if one application goes out of memory? What if the JVM crashes? > Traditionally, the answer is "call Leon". In the new picture however, his > answer will be "well, that's not my responsibility anymore, is it?". If you're getting IAAS, it's not your responsibility indeed. > In an Amazon cloud it would probably mean that a server needs to be restarted > and/or re-provisioned. As long as there is no relevant persistent data stored > on the server, that should be OK. Indeed. > Anyway, I think we should add a use case about all bad stuff that can happen; > OOM, crashes, BSOD, hardware failure, power outage, etc. etc. and describe > who is responsible for recovering from the errors. Actually I think, since we pitch Amdatu as a cloud platfrom, that we should not deal with these use cases ourselves. That is also the reason why I think we should never run Amdatu without some kind of cloud abstraction layer in between: even if we run on a bunch of local machines, the lowest layer should always be some cloud platform software (Eucalyptus or something). > -2- Schema updates > Marcel stated "I'm actually wondering why you're stating that these rolling > updates are hard. What makes them hard? I can agree that doing schema updates > on relational databases as part of updates can be hard or time consuming, > especially if you need to be able to roll them back too, but since we're not > using relational databases anymore, and having one central database that is > used by all components is a bad idea from a component perspective anyway, I > don't see big problems" > > I don't think we don't do relational databases anymore. It is true that in > the current Amdatu implementation no RDBMS is used, but I think Amdatu should > support many storage engines and it's up to the application to decide what > storage is actually used. Furthermore, schema updates are hard most of the > times, not only with relational databases. For example, using Cassandra > (NoSQL) it is extremely hard; it is not supported at all. In SQL you could > write an update script, in Cassandra you just can't (CF's cannot be changed). > Schema updates are always a tricky thing and much harder then software > updates/rollbacks. I think in many cases schema rollbacks will even be > impossible, assuming you don't want to lose any data. In software, nothing is impossible. When doing an update, with SQL I can always first make a dump of the existing schema + data before I do the modification. NoSQL means that there is no fixed schema, so the problem is dealt with in a different way. > Thinking of it, the whole provisioning/update/rollback of an application is > much easier then update/rollback of persistent data. We're focusing on making > it extremely easy to manage distributed applications, where we should focus > much more on persistent data. Reliability of persistent data is much more > important than the application; software can always be reinstalled, lost data > is lost forever. I agree we should make sure we never loose data. I'm not so sure we should spend a lot of time worrying about schema updates. > So my point is that the use cases should focus more on dealing with > persistent storage. On one hand we say that any storage can be used and it's > up to the storage to support clustering, data synchronization, schema updates > and schema rollbacks. On the other hand, if we require this from a storage > engine, there are not many storage engines we support. My starting point is that it's up to the component to choose how it persists its data. With that as a starting point we should look at how to replicate data, handle updates, etc. So I don't agree we must use a storage engine that supports all of this itself. That is just one possible solution. > -3- Multiple composites > I agree that we should support running different components belonging to the > same application on different servers. I think we should not think about an > application "running on some server" anymore. An application doesn't run on a > server, it runs in the cloud and each node in the cloud provides a part of it. Agreed completely. This is the other way round from multi-tenancy (running multiple apps on one node vs running an app on multiple nodes). Both should be supported. Greetings, Marcel
