Amazon & Orgis IT

or There and Back Again...

In the last year, we came up with the conviction that we want to get the solution, which we provide, in the real cloud and not just on the virtualized background on the servers of local providers. Which were the basic reasons? 

How did it use to be?

Default Status

Small local providers usually offer the background right on the visualization and work with a static reserved pool of courses for a specific client. This pool is therefore quite hardly automatically changeable. Therefore, we have the choice of following possibilities on the local market:

 a) The provider is a company that knows marketing sales and how to set up nice prices, but in the past, there are such technical errors that you don´t think even about putting VPS to them, what more, to put the primary cloud to them. They sure have their customers, but these costumers are largely end users that have smaller claims on dynamics and they are not responsible for the availability of other subjects. Those solutions are available music for available money (as they say), but it is nothing for XaaS services. 

     b) Then, there are such players, and we are still partly under his care. They know how to serve the customer for a higher price than the previous case, bit they offer even superior services and clearer blackouts explanations. They have quite a large amount of possibilities, but those companies are being destroyed by the wheels of the corporate surrounding. Those companies have the basic company running problems and they are not able to keep up with others. So every scaling of the environment (doesn´t matter if RAM, disks...) have to be ordered via the Sales Department, sign !paper contract add-ons! and after some time the result appears. This quick action takes from 5 to 15 days. Can you imagine, what it means, if a customer comes and needs to increase the performance to 600% for Christmas and ideally for 14 days only? Before Christmas, they are on holidays and the increase happens 4th January after the peak. Yes, you can live with it, you just need a large amount of patience and three times larger reserve performance which you rather pay constantly, because with the cancellation of the increase is kind of problem. 

    c) In some cases, some unnamed providers appeared which had „a flexible allocation“ of sources and the solution was obviously not feasible or expensive and paid for it. The wasn´t enough of market power for the solution to be big enough and could compete with its flexibility. 

It is completely missing any possibility of dynamic source management. Or the possibility of update almost always has to be done manually, or you have to order many other steps. 

What possibilities do we have?

What cloud should we choose?

In the time of our choice, 3 providers came into consideration: Google Cloud Services, Microsoft Azure, and Amazon AWS. Google is ok, but there was something missing – boys tried to take it from another end and maybe it suffered on the clarity, so it fell out as first. We were interested in MSA and AWS so we compared them. I won´t write down why Amazon won in the end, but the number of aspects is really great, so the evaluation wasn´t easy. 

Those providers primary have a really modern conception, perfect automatic control, so you write robots almost for everything you need and you don´t have to search for limits – by these solutions, there aren´t any. Yes, you need to have people and possibilities to white it all down and to adapt everything on such a cloud, because every care is visible on the operation and mainly on the bills. Further, you don´t have problems with the allocation of the sources – you just choose as many as you can keep and use them however you want (although even here are some rules). Last but not least, those providers have many modern and cool services in their own implementations so it is more usable for the automatic operation.

Amazon offers a perfect documentation and perfect SDK perhaps for every language. The limit of the technical solution is the fantasy and time you have. We had time so we played with it into the detail.

The biggest hitch could be the price. It is multiple higher that the solutions of local providers. If you have some infrastructure in the prime cloud and you just put it into AWS, it can be extremely expensive. So you have to optimised, invented, searched and good implement. But even though, it is more expensive.

Meeting Amazon

In Amazon, you find almost everything you could need. The service is available through comfortable API usage without the low level configuration caring. Everything runs and you pay just for what you need. The question is how much you want to be bind to the Amazon services that some deep vendor lock wouldn’t be created. In principle, everything can build the way that you use only computing power and RAM, or even only serverless services from Amazon. 

In Orgis we have quite robust application – the solution´s architecture took around half a year so the operation would be really enjoyable – so we didn´t have it really easy. Except the things mentioned above, you find here databases – relational and unrelated, docker containers, data evaluation and analysis and that everything as service – if you don´t want anything complicated – you don´ have to edit it. 

Another nice thing is that there is a tool available for the evaluation of workload of individual services which can be limited or further modified if something unexpected happens and in these cares to write down robots which will respond instead of you. This all can be tracked even in billing console which tracks the increase of used money for given services and offers some optimisations.

It is a little bit different philosophy in the IT and services on which you get used to really quickly and then you will think that there is no other way. You don´t solve a question like the running of servers and connectivity if you have to add RAM modules or to change servers and no crashes and data recovery. This all brings the outage time and lower availability of services which is paid by the trust and your money.

We see this way of operating as the only one that is meaningful at the time.

Odoo in Amazon hosting

We came to Amazon mainly because of the Odoo system which we host for our customers all around the globe. We used to have customers only from the Czech Republic, so there were no problems for the hosting. But now we host Odoo in many countries and therefore we had to choose the way of AWS. Odoo application is extremely huge and robust ERP system which is not ready for some optimisation run in the cloud environment, where every detail matters because of the support. In this case, we tried out that every application can be prepared for AWS:  

 The advantage of hosting of Odoo in Amazon (AWS) is mainly by the security of availability and the dynamic in the source obtaining. We help every customer to add so many performances, as they need and eventually to bill back his overlimited usage. Further the dynamic allocation of the disk space, connectivity, gaining the security and the protection against DDoS. By the comparison with the hosting on the standard services, the need of the HW solving or the management of the websides themselves drop off. 

 Last but not least, all processes can be scripted and prepared so the constant routine intervention in the infrastructure won´t be needed. Instead those repeating action, we can spend the time on the development and improvement of our services. From the certain dimension of the operation is this regard mode substantial. 

Money, Money, Money ...

It´s expensive. Optimisation pays off.

Maybe the most important thing, which dissuades almost every company from the usage of cloud services of this kind, is the price. If you take an application such as Odoo (or any other) and put it in AWS, you find out that if you need the sources top, so the price will still be relatively high – and that multiple times compared to the classical hosting on the servers of local providers. 

Without large preparations, the optimisation of the application and the scaling of the logic it will never be. So, the application that you´d like to support you have to either from the beginning build it with the intention of the could service infrastructure (which could be definitely better way), or by the current architecture, you have to find a way how and where to save on scaling, suitable server programme, choice of suitable service (Amazon has specialized services for some processes, which allows considerable optimisation) and many other.   

The aim of this article was to get you familiar with the way how it works by us and on what we nowadays work. I hope that we capture the ain why we came to other provider and what is the amazing advantage of this stop, the right way. 

I also hope that you´ll see the meaning in the reality, that in Orgis, we are trying to keep going on improvement and development of our services toward you. You are our motivation!


Give us your phone number and we will call you back.