Project Peach
WebApps: Easy Rubber Stamping & Distribution
We need a modern browser to run our WebApp. Because you have either a legacy browser or have javascript disabled this is the best we can do!
WebApps: Easy Rubber Stamping & Distribution
A Tale of Types & Instances
So you're not a programmer. Then you've probably never considered types and instances or classes and objects. We're only mentioning here because it's a key concept in understanding how we rubber stamp our cloud hosted webapps. Consider an application on your desktop, say a text editor, you can open a single instance or perhaps two or three instances. Multiple programs of the same type that have different data, the text in the editor. That's our concept in the cloud. We've built a live webapp framework for creating cloud hosted applications. We've built a few stock 'types' ourselves. For example we have a retail webapp type, many of our eCommerce clients use this stock webapp. It's the same code, running in a different instance each with it's own unique data and branding. Whatever types of webapps we, or you write, it's the same simple creation process to bring a new client online. It's simply another instance of the webapp type. Ok, that's the theory over.
Application Instance Manager: Webapp Genesis
We've a webapp in our cloud called the Application Instance Manager (AIM) that manages our cloud hosted webapps. It's built on top of the exact same live webapp software framework as all the other great webapps we write. It's role, amongst other things, is to govern the relationship between our webapp types and their instances. Webapp creation, deletion, stopping, starting, backing up, updating, installing to name but a few. We use this admin mechanic tool to create a new instance of a webapp type. We'll cover the other functionality in future blogs. Let's see just how easy it is to create a new webapp instance. This is how we bring a new customer online. Let's take our retail/eCommerce type as an example.
Here's our AIM's types view. All the webapps you see here are a type of webapp. From each of these types we can have multiple instances. Take a look down the list and focus on ProjectRetail. You can see that there are 3 instances of which 3 are running, hence 3/3. Remember at this level we are taking about the webapp program. It's the same program for ALL running instances of this type.
We've clicked the ProjectRetail webapp type and navigated down to the running instances of this type. You can see the three live webapps sharing the same code base. At this level we can control individually each webapp without affecting the others or update all customers by updating our software and doing a stop / start in the cloud. If we want to bring a new customer on board we simply add another instance.
We've just clicked the little spanner at the top of the Project Retail instances list to see our options. Remember that these action relate to ALL webapps of the type. In the choices there's 'Add Instance'. Simple, we're 3 clicks in and all we have to do is complete a simple form. Congratulations, we're all done, but what happens next?
A New Webapp Instance is Born
Immediately the form is completed a new webapp instance of that type is created and started. Our live webapps OWN their own data structures and have the responsiblity of creating them, this includes any associated database schema. So it's all ready to go BUT how do you access it? Live webapps are accessed via an URL so we simply send an automated email with a link to copy or click.
Congratulations. You're new webapp is now an instance in our cloud. We monitor these instances for faults 365/24/7 both in our admin panels, AIM and our Project Peach app instance health dashboard. Any wobbles we know.
The Future's so Bright...
It's really, really easy to duplicate or rubber stamp our types. It would be only one further step for us to automate the entire process and put it in our user's control via self service. Let's step back a bit first. Currently we ship our stock webapps with a single default visual template. The idea being that a web designer and graphic artist can tailor it specifically to brand, after all it's simply HTML/CSS for the visuals. We've clear demarcation between our functional coding and our visual design. It's not too big a leap of thought to consider selecting from a range of ready made visual styles. We made it this way by design. Custom or tailor, your choice. Consider what this means for a hosting provider. A top of the range webapp of a specified type that's easily reproduced potentially under a self service structure with value add upsell of customisation to brand available. Imagine a retail/eCommerce webapp as advanced as for all. It sure beats a website builder. Best of all we continue to improve features all the time. There's no install or update to device it's in the cloud. We've a whole automated build, install and rollback process but that's again for a future blog.
John Ince