Cloud & PaaS · Architecture, hosting and operations
Cloud that fits the workload. And a bill you can explain.
Jelastic PaaS, containerization and cloud-native architecture for solutions that scale with demand. For an SME the question is rarely which cloud is best. It is where each application should run, what that costs per month, how it gets deployed and who notices when it stops. A4IT designs that, sets it up and keeps it running.
Scope Deliverables Engagement Technology Good fit / not a fit FAQ
What you get, what stays yours, where it stops Said before the first meeting
You get
A written target architecture with the reasons behind every choice
Environments for test and production, built the same way and documented
A deployment pipeline, so a release is a button and not an evening
Monitoring, backups and a restore that has been tried, not assumed
Stays yours
The accounts with cloud and hosting providers: in your name, with your access
Your data, your backups and the choice of the region where they are stored
Source code, pipeline definitions and configuration, in your own repository
The freedom to move: we document how to leave as well as how to arrive
Boundaries
No uptime guarantee from us beyond what the underlying provider commits to
No promise of unlimited scale: capacity follows architecture and budget
No partner or reseller status claimed with any cloud vendor
No migration without a tested way back to the old environment
What we deliver Seven building blocks · take one or all
01 · Start here
Cloud assessment and architecture
An inventory of what you run today and a decision per application: move, rebuild, replace or leave where it is.
Inventory
Applications, databases, file shares, integrations and the people who depend on them. Including the server under a desk nobody dares to switch off.
Decision per workload
Not everything belongs in the cloud. Each workload gets a recommendation with the reason, the effort and the expected monthly cost.
Target architecture
Environments, networks, databases, access and backups on a few pages, with diagrams your next IT supplier can read too.
Data location and access
Which data sits in which region, who can reach it and how. Personal and confidential data are marked from the start.
Environment setup
Application servers, databases and load balancing assembled into one environment, for Java, .NET, PHP, Node.js or container-based applications.
Scaling with demand
Resources grow and shrink with the load within limits you set. The limits are the guard against a surprise on the invoice.
Test and production alike
A test environment that mirrors production, so what was approved in test behaves the same after release.
Provider choice
The platform is offered by several hosting providers. We help choose one on location, support and price, and note what moving away would take.
Containerization
Existing applications are packaged into images with their dependencies. Installing by hand, and the differences that come with it, disappear.
Configuration outside the image
Settings and secrets are supplied per environment and never baked in. One image goes from test to production unchanged.
Stateless where possible
Data lives in the database and in storage, not in the container. That is what makes adding a second instance a setting instead of a project.
As simple as the case allows
A handful of containers on a PaaS is often enough for an SME. We do not introduce an orchestration platform your team cannot maintain.
Subscription structure
Subscriptions, resource groups and naming set up so that cost and ownership are clear per application and per environment.
Compute and data
Virtual machines, application hosting and managed databases such as SQL Server and PostgreSQL, sized for the real load.
Identity and access
Sign-in through the accounts your staff already have, with roles that give each person and each service only what is needed.
Hybrid setups
Part in Azure, part on your own servers or on a PaaS, connected securely. See
hardware & network for the on-site side.
Version control
Everything in Git: application code, database scripts, pipeline definitions and environment configuration. One history, one place to look.
Build and test
Jenkins builds every change and runs the automated tests. A failing build stops there and tells the developer why.
Release with approval
Deployment to test is automatic, deployment to production waits for a person. Who approved what, and when, is on record.
Rollback
The previous version stays available. Going back is a defined step that has been practised, not an improvisation at night.
Monitoring
Availability, response time, disk, memory and failed jobs, with alerts sent to someone who can act on them.
Backups
Databases and files backed up on a schedule, kept for a period you choose and stored away from the system they protect.
Restore tests
A backup counts once it has been restored. We restore on a schedule and record how long it took and what was missing.
Recovery plan
A short document: what to do in which order, who calls whom, and how much data and time you have accepted to lose.
Cost per application
Resources are labelled so the invoice can be read per application and per environment. You see what each one costs per month.
Right-sizing
Oversized servers, forgotten test environments and unused storage are found and cleaned up, with your approval per item.
Migration in steps
One application at a time, with a trial run on a copy of the data, a planned switch-over and the old environment kept as a way back.
Budgets and alerts
A monthly budget per environment and a warning before it is exceeded, not an explanation afterwards.
How an engagement runs Small steps · a decision after each
Intake
A call of thirty minutes: what you run, what hurts, what must not change.
30 minutes Assessment
Inventory of workloads and a recommendation for each, with expected cost.
Report + decision Design
Target architecture, environments, access, backups and the migration order.
Agreed design Build and migrate
Environments and pipeline set up, applications moved one by one with a way back.
In production Operate
Monitoring, restore tests and a periodic review of cost and capacity.
Running and checked
Technology Chosen per case · nothing is mandatory
Platforms Jelastic PaaS, Azure, or your own servers where that is the better answer
Packaging Containers, with configuration and secrets kept outside the image
Operating systems Linux and Windows Server
Data PostgreSQL and SQL Server, with scheduled backups and tested restores
Delivery Git for version control, Jenkins for build, test and deployment
Operations Monitoring and alerting, cost labels and budgets per environment
Good fit, and not a fit Saves both of us a meeting
A good fit when
An application outgrows the server it started on
Releases are manual, rare and a little frightening
The cloud invoice rises and nobody can say which part is needed
You want hosting and software handled together, with knowledge of both
Not a fit when
You need a staffed operations centre that watches screens day and night
The goal is to be in the cloud, whatever the workload needs
You want the cheapest hosting with no backups and no monitoring
A formal vendor partner status is a requirement in your tender
01 Where is our data stored? Where you decide. Region and provider are chosen during the design and written down, including where the backups go. If data has to stay in the European Union or in your own building, the architecture is built around that.
02 Why Jelastic PaaS and not only one of the large clouds? For many SME applications a PaaS gives scaling and managed environments with less to configure and a bill that is easier to read. For other cases Azure is the better choice. We recommend per workload and explain why.
03 Does everything have to move to the cloud? No. Some systems are cheaper, faster or simply fine where they are. The assessment says so per workload, and a mix of cloud and on-site infrastructure is a normal outcome.
04 What will it cost per month? That depends on your workloads, so we do not quote a figure before the assessment. Afterwards you get an estimate per application, and once it runs, the real cost per application with a budget alert.
05 Are we locked in to you or to a provider? Accounts are in your name, and code, pipelines and configuration sit in your repository. Containers and standard databases keep the application portable. What a move to another provider would take is part of the documentation.
06 Who do we call when something is down? That is agreed before go-live and written in the recovery plan: who gets the alert, how to reach A4IT and what the provider handles. We do not promise response times on this page; they are set per agreement.
Bring one application and its invoice. We will tell you where it should run.