Uh Oh! It appears you're not connected to the internet!
Sorry! We currently have more users than we can cope with. You can either wait until a space becomes available or come back later. We will be upgrading our servers to cope with this soon!
You got the boot! Click to connect back up...
Please contact an administrator, You are not authorised to login via this IP address
Already have an account?
Click here to login
Don't have an account?
Click here to sign up
Go check your email!
Oops! We don't know your email address, We can't send you a new password! Contact an Admin
Set Profile Picture
Select An Image
Confirm End Of Friendship
Chat To Us
Prefer to chat anonymously?
Read all about it, See what the good people at Project Peach have to say
Our web applications run in the cloud. What does this actually mean?
What's in Our Cloud?
What's in Our Cloud?
We're telling you that we run web applications in the cloud. What does this actually mean? What's our infrastructure, software and webapp management really like? Want to be amazed and enlightened, read on...
The Cloud, Our Definition
So what exactly is cloud computing? It's an ambiguous statement that seems to mean different things depending on your viewpoint. From our point of view we go for the classic definition "...a type of computing that relies on sharing computing resources rather than having local servers or personal devices to handle applications". Our web applications run remotely on a server and share both hardware and software. From a hardware perspective we have multiple webapps running on the same physical server and from a software point of view we have multiple connections/users each sharing a single webapp of their choice. For example we have Cash Clamber, Project Peach & Eyesshare webapps all running on the same server. Cash Clamber users ALL connect to the same Cash Clamber webapp. That's it in a nutshell. Our cloud sharing both hardware and software resources. We don't install anything on your device.
Where is this Cloud? It's Anywhere!
We can run our live webapps locally on a laptop just like a device installed app with a browser UX (User Experience). Indeed this is how we develop a live webapp for a client in the first place, locally on the one machine. So it works on a single computer. What about an Intranet, a private company wide network? Of course. We own and coded our entire software stack from the ground up. We can install our cloud software infrastructure privately to your company. We normally run our webapps on either a dedicated server (a computer in a rack at a hosting company) OR a shared VPS (Virtual Private Server at a hosting company), a VPS is a slice of a server shared with many other companies to reduce costs. The choice is actually yours. As long as you can give us remote access we can configure the server remotely. The essence of this is that we can host big or small depending on your expected traffic. Where, It's up to you! If you're a small business we can accommodate you in our own cloud. But what about the tiny world like device hosting? A mobile phone or an IoT (Internet of Things) device? Sure! Our core webapp framework has a tiny software footprint with a great browser UX for control or information display. What about huge? How's it scale upwards? In exactly the same way as regular web server farming with load balancing switches, that's just a way to share load across multiple server computers. Please feel free to ask us more about our infrastructure.
Do these Cloud Webapps need a Web Server?
Technically No, but normally Yes! What a great, woolly answer. Let's explain. It depends on the type of webapp. We've a layered software architecture from low level system components to our higher level webapp services. The entry point to our software services is at any layer so if you don't need a UI (User Interface), you don't need a web server. If it's one of our stock, out of the box, live webapps it's almost certainly going to have a browser hosted UX, so yes you need a web server installed. So what do we use this web server for? Simply to serve template HTML, serve images used in the UI and make on-the-fly language translations. That's what a web server is designed to do, serve files! All our core functionality and your business logic is in the webapp which is totally distinct from the web server. We do however use a tiny bit of PHP (a web server computer language) glue for bridging both worlds, web server to webapp and visa versa. If your hosting device doesn't have a web server, we can write you a simple one or you may not need one at all. Our architecture is very flexible by design. Remember that the key here is that we don't write websites, we write true native code applications that appear to run in a browser.
Are you Tied to any Specific Server Technology
Currently we only have a Microsoft Windows Server Implementation. However from the outset we designed our architecture to be open and OS (Operating System) independent. Our webapps and webapp framework are written in portable c/c++ language. We simply need to port (rebuild) our software for your target environment. So if your preference is Windows/IIS (Internet Information Server) or LINUX/Apache then no problems. Whatever your OS we can port it over, as long as there is a c++ compiler available, if not we'll write you one! We love this none vendor tie-in model and it's key to everything we do. We want choice for our customer's projects.
Must Take You Ages to Configure a Server?
It doesn't really! Take AIM, fire! Our AIM (Application Instance Manager) makes our server configuration very easy and quick. We use it to create and manage our/your cloud and to install and update our webapp software automatically. It does much, much more but we'll get to that! You'll have noticed the word 'Instance' in the middle and hopefully your head didn't start to wobble. Let's try to explain this 'Instance' thing simply. Before we start let's think about the world you know, say Microsoft Windows Notepad, you can open a single document BUT you can also open another document in another 'Instance' of Notepad. Two running instances, same code BUT different data. With that firmly in mind let's return to webapps. We've the exact same idea here too. There can be a single instance or many instances with different data. WOW. wobble, wobble... Let's try an example. Our Cash Clamber 'type' webapp, there's only one instance and all our users connect to it! However we also have a retail 'type' webapp. Each retail store gets their own unique webapp and data BUT it's just like the notepad example above, a different Instance of the exact same code/program. So we can have say six instances of a retail webapp 'type' for six companies all with different look & feel and their own distinct data. But they all share the same code base. When we update our retail webapp 'type' software they all get the changes and improvements since they share the exact same code base. Summing up we can run single instances of a webapp OR many instances of the SAME 'type' of webapp. Each Instance is completely unique, can look entirely different and accesses its own private data. But they share the same code base. Our AIM manages our cloud(s) webapp(s) using a simple browser UX. That's it! Still don't get it? If you're interested we can live demo it for you! That'll bring it to life!
How do we Bring Online a Webapp for a New Customer?
Firstly, let's concentrate on one of our off-the-shelf webapps. This is the type we talked about previously with multiple instances of the same 'type' of webapp. Say we've just had a retail webapp demo request from our Project Peach website, how do we make it happen? Simple, we login to our AIM from a browser, fill out a simple dialog and click create. The whole process is done in seconds and the client is emailed an URL to access the new webapp. Behind the scenes the AIM simply builds the folders needed and fires up another instance of the retail webapp type. The webapp 'type' is responsible for creating its own data structures. It really is a simple admin job that's also well suited to automation. We could easily automate the entire process. It gets better too. We can put expiry dates on our demo webapps to time out after a set period. If we have a new type of webapp, custom written for ourselves or a client, we simply use the AIM's excellent webapp automatic installation process, it's one click. We're then free to add multiple instances if it makes sense to do so. When there are software updates to make our AIM is single click update process. It's simply administration. We automate ourselves as well as our customers!
How do you Customise our WebApp to our Brand
So once we've created our webapp and the client/ourselves have the link to access the webapp in a browser what does it look like? It's a naked template ready for our painting to brand. We've clear demarcation between our coding and our visuals. We can make the webapp look exactly how you want it to look. There's no need for coding and any competent graphic designer with a knowledge of web design can do it. Because it's part of our framework there are a few rules to follow but these are consistent and are easy to learn. We've a few templates that are examples too. It's a nice up selling model too. All the functionality is built in and we simply custom spray to your exact brand. Depending on the complexity of the client's needs this process takes between 1 hour and 1 day. We a growing list of templates that cuts down the time taken.
What Else can this Magical AIM do?
Since our AIM is responsible for installing, updating and starting all the webapps on a server then it makes perfect sense that it's also responsible for checking their health. Our webapps are long running, sometimes for months on end, so we need to know that all is well. So our AIM has a watchdog feature, monitoring the webapp connection and responses by exchanging heartbeat messages. These messages are processed in the same way as our conventional webapp application messaging system. Our AIM UI shows the status of the heartbeat but it also has the ability to automatically restart a webapp if it feels that it's flat lining. But there's more. All our AIMs, across all our servers are centrally connected to our Project Peach dashboard. If an AIM senses a wobble or a webapp has an issue the AIM is informed and this is passed back to our central control dashboard. We know the instant a problem occurs and our administrators can drill down to the problem webapp without leaving their seat. We know all the errors, either cloud side or browser side, right down to the exact line of code. Magical, simple and easy!
It Writes our PHP Glue Code all by Itself
Since we enter our live webapps with an URL we need to bridge the conventional web server world with our live webapp world. If we've multiple live webapps running on the same server then we need to make sure that our entry URLs end up at the correct destination. There's other website related stuff too, we can upgrade a HTTP entry point to HTTPS, we can redirect different associated domains to the same domain and much more. Conventionally, in order to do this, we need to write a bit of PHP code. But wait... Why write any code at all? Our AIM has all the information from our configuration settings, so why not let it write PHP automatically? So it does. An app writing an app! We like the sound of that automation. Add a new webapp and the PHP glue code gets updated automatically. We're just a bit proud of our live cloud architecture and it's automation.
Need a Private Demo of our Cloud Power?
We're more than happy to give you a demo from your desk. We simply send you a link, you see our desktop and we'll talk you through our cloud AIM process with a live demo.
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.