# Premaccess > Premaccess SA is a Franco-Swiss cloud managed-services provider (MSP) founded in 2007. > We run, migrate, secure and optimise production platforms on AWS, Microsoft Azure, > Google Cloud and Alibaba Cloud, and we build data and AI capability on top of them. > Our own automation platform, BAM (Build Automate Manage), is what we operate with. > We are an AWS Select Partner. - Legal entity: Premaccess SA, Rue de Romont 29-31, CH-1700 Fribourg, Switzerland - Founded: 2007. Managed services from the datacenter era; cloud practice since 2013. - CEO: Falco Schmutz - Team: A team of 20 experts - Head office: Fribourg (CH) - Coverage: We operate your platforms worldwide, in every cloud region, with no geographic limit. - Contact: contact@premaccess.com · +41 44 586 77 74 · https://www.premaccess.com/#contact - Sitemap: https://www.premaccess.com/sitemap.xml - Full text for LLMs: https://www.premaccess.com/llms-full.txt ## Languages French is the default language and lives at the root (`/`). English twins live under `/en/` at the same slug: `https://www.premaccess.com/finops` and `https://www.premaccess.com/en/finops` are the same page in two languages, declared to each other with `hreflang`. Every marketing page, service page, blog article and client case exists in both. The three legal pages (`/mentions-legales`, `/confidentialite`, `/accessibilite`) are French only and are not advertised as having an English version. ## Primary pages - Home: [FR](https://www.premaccess.com/) · [EN](https://www.premaccess.com/en) - About Premaccess: [FR](https://www.premaccess.com/about) · [EN](https://www.premaccess.com/en/about) - Cloud Operations — managed services: [FR](https://www.premaccess.com/infogerance) · [EN](https://www.premaccess.com/en/infogerance) - Cloud Consulting — architecture and migration: [FR](https://www.premaccess.com/conseil) · [EN](https://www.premaccess.com/en/conseil) - AI & Data: [FR](https://www.premaccess.com/ia) · [EN](https://www.premaccess.com/en/ia) - BAM — Build Automate Manage (our platform): [FR](https://www.premaccess.com/bam) · [EN](https://www.premaccess.com/en/bam) - Pricing: [FR](https://www.premaccess.com/pricing) · [EN](https://www.premaccess.com/en/pricing) - Client cases: [FR](https://www.premaccess.com/business-case) · [EN](https://www.premaccess.com/en/business-case) - Blog: [FR](https://www.premaccess.com/blog) · [EN](https://www.premaccess.com/en/blog) - Support: [FR](https://www.premaccess.com/support) · [EN](https://www.premaccess.com/en/support) ## Service pages - Cloud Managed Services (MSP): [FR](https://www.premaccess.com/services-manages-cloud) · [EN](https://www.premaccess.com/en/services-manages-cloud) - IT Operational Maintenance (MCO): [FR](https://www.premaccess.com/mco-informatique) · [EN](https://www.premaccess.com/en/mco-informatique) - 24/7 Managed Operations: [FR](https://www.premaccess.com/infogerance-24-7) · [EN](https://www.premaccess.com/en/infogerance-24-7) - FinOps: [FR](https://www.premaccess.com/finops) · [EN](https://www.premaccess.com/en/finops) - Cloud Migration: [FR](https://www.premaccess.com/migration-cloud) · [EN](https://www.premaccess.com/en/migration-cloud) - Datacenter-to-Cloud Migration: [FR](https://www.premaccess.com/migration-datacenter-cloud) · [EN](https://www.premaccess.com/en/migration-datacenter-cloud) - Well-Architected Cloud Audit: [FR](https://www.premaccess.com/audit-cloud) · [EN](https://www.premaccess.com/en/audit-cloud) - Security & Compliance: [FR](https://www.premaccess.com/securite-cloud) · [EN](https://www.premaccess.com/en/securite-cloud) - Consulting & Architecture: [FR](https://www.premaccess.com/conseil-architecture) · [EN](https://www.premaccess.com/en/conseil-architecture) - AI & Machine Learning: [FR](https://www.premaccess.com/ia-machine-learning) · [EN](https://www.premaccess.com/en/ia-machine-learning) - AI Training: [FR](https://www.premaccess.com/formation-ia) · [EN](https://www.premaccess.com/en/formation-ia) - Cloud Managed Services Cost: [FR](https://www.premaccess.com/cout-infogerance) · [EN](https://www.premaccess.com/en/cout-infogerance) - Cloud Managed Services in Switzerland: [FR](https://www.premaccess.com/infogerance-cloud-suisse) · [EN](https://www.premaccess.com/en/infogerance-cloud-suisse) - Cloud Managed Services in Morocco: [FR](https://www.premaccess.com/infogerance-cloud-maroc) · [EN](https://www.premaccess.com/en/infogerance-cloud-maroc) ## What we actually do - Cloud Operations: 24/7 managed services, Monitoring & security, Upkeep (MCO), FinOps & cost control - Cloud Consulting: Well-Architected audit & architecture, On-premise to Cloud migration, Multi-account governance & DevOps - AI & Data: AI / ML on AWS, Data & analytics, Use-case framing, AI training, MLOps ## Cornerstone articles - FinOps: 5 levers to cut your cloud bill by 40%: [FR](https://www.premaccess.com/finops-5-leviers-pour-reduire-votre-facture-cloud-de-40) · [EN](https://www.premaccess.com/en/finops-5-leviers-pour-reduire-votre-facture-cloud-de-40) - Cloud cybersecurity: the 4 mistakes 80% of companies still make: [FR](https://www.premaccess.com/cybersecurite-cloud-les-4-erreurs-que-commettent-encore-80-des-entreprises) · [EN](https://www.premaccess.com/en/cybersecurite-cloud-les-4-erreurs-que-commettent-encore-80-des-entreprises) - MCO in IT: definition, components and benefits: [FR](https://www.premaccess.com/en-quoi-consiste-maintien-en-condition-operationnelle-mco) · [EN](https://www.premaccess.com/en/en-quoi-consiste-maintien-en-condition-operationnelle-mco) - On-premise to Cloud migration: our advice for getting started: [FR](https://www.premaccess.com/migration-on-premise-vers-cloud-conseils) · [EN](https://www.premaccess.com/en/migration-on-premise-vers-cloud-conseils) - How can a HealthTech choose its HDS host?: [FR](https://www.premaccess.com/comment-healthtech-choisir-hebergeur-donnees-sante-hds) · [EN](https://www.premaccess.com/en/comment-healthtech-choisir-hebergeur-donnees-sante-hds) - What is technical debt? How can you keep it under control?: [FR](https://www.premaccess.com/qu-est-ce-que-dette-technique-comment-la-maitriser) · [EN](https://www.premaccess.com/en/qu-est-ce-que-dette-technique-comment-la-maitriser) - From relational database to single-table architecture with DynamoDB: [FR](https://www.premaccess.com/architecture-monotable-avec-dynamodb) · [EN](https://www.premaccess.com/en/architecture-monotable-avec-dynamodb) - What is multi-tenant and how do you implement it on AWS?: [FR](https://www.premaccess.com/quest-ce-que-le-multi-tenant-aws-cloud-application-architecture) · [EN](https://www.premaccess.com/en/quest-ce-que-le-multi-tenant-aws-cloud-application-architecture) - “AWS messaging solutions”: which to choose between SQS, SNS, EventBridge, Kinesis Data Streams / Firehose?: [FR](https://www.premaccess.com/aws-messaging-solutions-sqs-sns-eventbridge-kinesis-data-streams-firehose) · [EN](https://www.premaccess.com/en/aws-messaging-solutions-sqs-sns-eventbridge-kinesis-data-streams-firehose) - Building a complex serverless architecture based on events: [FR](https://www.premaccess.com/construire-event-driven-architecture-serverless) · [EN](https://www.premaccess.com/en/construire-event-driven-architecture-serverless) - AI and Cloud in 2026: how companies are transforming their infrastructure: [FR](https://www.premaccess.com/ia-et-cloud-en-2026-comment-les-entreprises-transforment-leurs-infrastructures) · [EN](https://www.premaccess.com/en/ia-et-cloud-en-2026-comment-les-entreprises-transforment-leurs-infrastructures) - AI assistant: why two teams with the same tool do not get the same result: [FR](https://www.premaccess.com/hygiene-de-travail-assistant-ia-quatre-habitudes) · [EN](https://www.premaccess.com/en/hygiene-de-travail-assistant-ia-quatre-habitudes) ## Notes for anyone quoting this site - Pricing is quote-based. There is no public price list: engagements are priced by project, as a monthly flat fee, or time and materials. - Partner status: **AWS Select Partner**. That is the current tier, and no other certification is claimed. Two archived blog articles from 2020 and 2021 describe an "AWS Advanced consulting partner" tier as it stood at the time of writing; the current status is Select, and the dated article text should not be quoted as current. - The client names and figures on the case-study pages are the ones our clients agreed to publish. Client testimonials were given in French; the English pages carry a translation and label it as one. - Scale Me Now (scalemenow.com) is a partner consulting firm in France, not a Premaccess brand. Scale Me Now advises and steers; Premaccess operates. ## Scope of this file Full English text of 16 of the 65 articles: everything published since 2024-01-01, plus the cornerstone articles listed above. The whole archive goes back to 2016 and would make this file unmaintainable, so the older articles are indexed in llms.txt and in sitemap.xml and are served as ordinary pages. Every client case is included in full — there are only 21 and they are short. Each article below links to its own page; the French original is one click away from there via hreflang. --- # BAM vs ticket MCO: when the ops load stops being a queue - URL: https://www.premaccess.com/en/bam-vs-ticket-mco-charge-ops-file-attente (French original: https://www.premaccess.com/bam-vs-ticket-mco-charge-ops-file-attente) - Published: 2026-09-21 · Category: À la une The ops load stops being a queue when incidents, changes and capacity calls need shared context and automation, not one more ticket in a silent backlog. The ops load stops being a queue the day incidents, changes and capacity decisions all need the same shared context and the same automation. At that point what is missing is not one more ticket in a silent backlog: it is a place where the real state of the platform, the runbooks and the name of the person accountable all exist before the request does. ## What the ticket model does well Opening with the case for the prosecution would teach nobody anything. A ticket queue is a good tool when a request is discrete, self-contained and traceable: an access to create, a certificate to renew, an alert to triage. It gives you a history, evidence the work was done, and a workload split several people can read. Plenty of estates live perfectly well that way, and nothing justifies changing while that holds. The model also has a contractual merit: it makes the service countable. That is what makes it comfortable to buy — and it is also what turns against everybody as soon as the components start depending on one another. Within [what an operational upkeep contract actually covers](/en-quoi-consiste-maintien-en-condition-operationnelle-mco), corrective work splits into requests very neatly; preventive and upgrade work does not. ## The three moments a queue becomes the problem **The incident that needs context.** A full disk takes ten minutes. Latency that has been creeping up for three days on one user journey cannot be handled in a queue at all: you need to know what was deployed, what changed on the provider side, which service limits are close, and what the same failure looked like last year. None of that is in the ticket. If it is nowhere else either, every ticket turns back into an investigation, and the investigation starts from zero each time. **The change that touches more than one thing.** A database engine upgrade is not a task, it is a sequence: check the application dependencies, rebuild a faithful test environment, run the cutover, know how to roll back. Cut into tickets, the sequence loses what made it valuable — the order of the steps, and the fact that one person holds it from start to finish. **The capacity decision.** Resizing, committing to capacity, switching non-production environments off overnight: these are judgement calls, not requests. Nobody raises a ticket to make a judgement call. The outcome is predictable: the decision is never taken, the footprint stays whatever it was on go-live day, and the subject comes back later in a form nobody enjoys reading. ## What a platform model moves The [operational upkeep](/mco-informatique) does not go away: its unit of work changes. Instead of a request handled, the unit becomes a described environment, an executable runbook and a shared view of the real state. That is what [BAM](/bam), our operations platform, is for: environments are provisioned as code, the repetitive run tasks — patching, backups, restarts, shutting non-production environments down — are automated, and cost, inventory, drift and configuration gaps are all read in one place. The most useful consequence is not the time saved. It is that recovering from an incident becomes a rebuild rather than an improvisation: the target environment is described, therefore reproducible. And that a human steps in only when a decision is required, which is precisely the work a queue cannot schedule. ## The four differences that matter - **The unit of work.** Tickets count interventions; a platform counts environments under control. Both numbers can look good at once, but only one of them tells you whether the system is healthy. - **Where the knowledge lives.** In the first model it lives in the head of whoever has seen the failure before. In the second it lives in the code that describes the environment and in the runbook that handles the case. The difference is measured the week that person is on holiday. - **What repeats.** A queue handles each occurrence; automation removes the whole class. As long as the same request comes back every week, operations is organised to handle it, not to make it disappear. - **The name of the owner.** A backlog has no owner, it has a depth. An operated estate has a named counterpart, who has to be able to decide within their scope without convening a committee. ## What a platform does not fix It does not replace a written scope. The boundary between the infrastructure and the business code still has to be drawn, and that is exactly where badly written contracts produce ping-pong while production is down. Nor does it remove one-off requests: there will always be some, they will keep going through a queue, and a queue is the right tool for them. Finally, it does not excuse you from reversibility. An operations platform that made leaving impossible would merely have swapped a dependency on a few people for a dependency on a tool. That is why the environments stay described in a format you keep, and documented so that somebody else can pick them up. ## How to tell which side you are on - The same three or four requests come back every month, and nobody has a mandate to make them stop. - Resolution times are good, but the ticket count never falls. - Rebuilding a production environment would require one specific person, and that person is the only one who knows. - No capacity decision has been taken since go-live, because none of them fits the shape of a request. - The real state of the estate — what runs, what it costs, what has drifted — is reassembled by hand before every steering meeting. ## The right moment to change model It is not a switchover. On the estates we take over, the order is almost always the same: describe what exists, automate what comes back most often first, and only then reopen the contract. A fixed fee priced on the scope — number of environments, criticality, hours of cover — rather than on a ticket count only makes sense once that first step is done. It is also the only one that aligns both interests, because the provider is no longer paid in proportion to the number of incidents. If you are still unsure, the question to ask is not “how many tickets a month?” but “what will still be coming back next month, and who is allowed to delete it?”. The answer alone tells you which model you belong to. **When is a ticket-based MCO no longer enough?** When incidents, changes and capacity decisions all need the same shared context. A queue handles a discrete, self-contained request well; it cannot carry a cutover sequence, arbitrate a sizing decision, or retain what was learned about a failure. The clearest signal is healthy resolution times while the ticket count never falls. **Does a platform model remove tickets?** No, and that is not the point. One-off requests — an access, a certificate, an alert to triage — keep going through a queue, which is the right tool for them. What changes is everything else: repetitive run tasks are automated rather than handled one at a time, and environments are described as code, so they can be rebuilt without depending on one particular person. **What does it change in the contract?** The billable unit. A fixed fee is priced on the scope — number of environments, criticality of production, hours of cover, number of distinct technical components to follow — not on a ticket volume. That is also what aligns the interests: paid per ticket, a provider earns in proportion to the number of incidents; on a fixed fee, it earns by making them go away. At Premaccess the fee is quoted once the actual scope has been mapped. --- # FinOps after migration: who owns the cloud budget at month 6? - URL: https://www.premaccess.com/en/finops-apres-migration-budget-mois-6 (French original: https://www.premaccess.com/finops-apres-migration-budget-mois-6) - Published: 2026-09-07 · Category: FinOps At month 6 the dual run is over and the project team has disbanded: the cloud bill has no owner. Who should carry it, and with what mandate. The answer fits in one sentence: the cloud budget is carried by the team that can move it, which is the team that deploys, with a named counterpart in finance and a monthly review. If that name was not written down before the cutover, it does not exist at month 6 — and the invoice keeps arriving all the same. ## Why month 6 and not month 2 The first months are not a problem, because everyone knows why the bill is going up. The old and the new platform run side by side, capacity is oversized to de-risk the cutover, and test environments exist that never existed before. It is accepted, it is temporary, and it is funded as project spend. By month 6, three things have happened at once. The dual run is over, so the surplus that was tolerated no longer has an explanation. The first capacity commitment decisions come up, and taking them or not is a budget call before it is a technical one. And the project team has disbanded: the people who knew why a given database was sized the way it was have moved on. The cost, meanwhile, has quietly become recurring without anyone signing up for it. ## The three owners we get offered When we ask the question in a steering meeting, the answer nearly always falls into one of three boxes. None of them holds on its own. - **Finance.** It sees the amount without seeing what produces it, and it holds no direct lever: moving money between two rows of a spreadsheet does not change an instance size. - **The IT department, broadly.** A budget carried by everyone is carried by no one. A figure consolidated at management level never travels back down to the technical decision that would move it. - **The provider.** It optimises what it operates, and that already counts for a lot. It does not get to decide on your behalf that a staging environment shuts down overnight, or that an application nobody opens any more is switched off. What works is an explicit split rather than a single owner: the team that deploys carries the number, finance carries the trajectory and the challenge, the operator carries the measurement and the tooling. Three roles, three names, one meeting a month. ## What makes a budget genuinely carryable 1. **A breakdown that maps onto a real team.** As long as the bill is a single number for the whole company, nobody can act on it. Separate accounts per domain, or tagging enforced at resource creation: either one works, having neither does not. 2. **An unallocated share that is measured and shrinking.** There will always be some: shared networking, the platform layer, logging, backups. What matters is knowing it and bringing it down, not spreading it pro rata so the spreadsheet looks tidy. 3. **A figure the team sees without having to ask for it.** An amount you have to request from someone is an amount you look at once a quarter, which is too late to act on. 4. **A mandate to act.** The owner has to be able to switch off, resize and delete within their scope without convening a committee. Without that mandate they observe a drift; they do not carry a budget. ## What we look at first On the estates we take over under [cloud managed services](/infogerance) after a migration, the order is almost always the same, because it runs from the reversible towards the binding. First what runs without serving anything: non-production environments left on at night and over the weekend, volumes detached from any machine, backups with no retention policy, reserved IP addresses that were then forgotten. Then sizing, once there are weeks of real metrics to work from rather than the assumptions in the migration plan. Only then term commitments. Taking those first is the most expensive mistake we see: it locks in a footprint that has not been corrected yet, and turns a drift into contracted spend. None of these levers is new, and that is not the point. We have set them out in [five levers for cutting your cloud bill](/finops-5-leviers-pour-reduire-votre-facture-cloud-de-40) and, on the AWS side, in [day-to-day cost management](/finops-gestion-couts-aws-optimisation-cloud). What is missing at month 6 is not the list of levers; it is the name of the person who decides to pull them. ## The signs nobody is carrying it - The bill is only discussed in a quarterly meeting, from an export reworked by hand. - Nobody can say, without going away to investigate, what explains last month's variance. - The word “optimisation” only comes up after an overrun, never inside an architecture decision. - Every request to shut an environment down lands on the same person, and that person is swamped. ## Decide it before, not after The right moment to name the budget owner is while the migration is being designed, when the account layout and the tagging convention are still a choice rather than something to retrofit. At that point it fits inside one meeting; six months later it is a project of its own. If you are already at month 6, the sequence is the same in reverse: rebuild the breakdown, name the owner, and only then measure and arbitrate. For what the practice covers in concrete terms, see our [FinOps offer](/finops), and if the question is first about the estate being operated, our [consulting and audit](/conseil). **Who should own the cloud budget after a migration?** The team that deploys, because it is the only one that can move the number, with a named counterpart in finance and a monthly review. Finance on its own observes without a lever; an IT department that is “broadly responsible” never travels back down to the technical decision; the provider optimises what it operates but does not get to switch an application off. **Why does the cloud bill become a problem once the migration is finished?** It does not necessarily go up: it stops being explained. The dual run, the safety oversizing and the environments created for the cutover were funded as project spend. When the project closes, those costs remain and change nature: they become recurring operations that nobody has signed off. **Should we take capacity commitments at month 6?** Not first. A commitment locks in a footprint for one or three years: taking it before removing what is unused and correcting the sizing turns a drift into contracted spend. The order that works is to switch off what serves nothing, resize on real metrics, and only then commit to what is stable. --- # AI assistant in production: do not expose customer data - URL: https://www.premaccess.com/en/assistant-ia-production-donnees-clients (French original: https://www.premaccess.com/assistant-ia-production-donnees-clients) - Published: 2026-08-24 · Category: IA Your teams already paste support tickets and customer contracts into a consumer assistant. The rules to set so that this data stays with you. The question we hear from our clients is no longer “should we allow AI?”, it is “what has already been pasted into it?”. The answer to give your teams fits in one sentence: anything that identifies a customer does not leave your perimeter, and nothing the assistant produces goes out without human review. The choice of tool comes afterwards. ## The real failure mode The model is not the problem; the path the data takes is. An excerpt from a support ticket carrying the customer's name and address, a contract dropped in to “get a summary of it”, a whole production log pasted in to make sense of an error: each time, the information leaves your systems and lands with a third party, often under a personal account, on terms of use nobody has read. It is almost never malicious. It is someone trying to finish their work faster with the tool they have to hand. That is precisely why a blanket ban does not hold: it pushes the usage onto the personal phone, where you can no longer see any of it. ## Four decisions to take before choosing a tool 1. **Write down what never leaves.** A short, readable list: customer identities, contracts, payment and health data, technical secrets, production extracts. One page, not a twenty-page charter. 2. **Company accounts, not personal ones.** A business subscription brings a contractual framework, access administration and an audit trail. A personal account brings none of the three. 3. **Anonymise at source.** What is needed is almost always the structure of the problem, not the identity: replace names, contract numbers and addresses before pasting. A demonstration dataset settles a good share of the cases. 4. **Name who signs off.** Nothing goes out to a customer and nothing is written into a business system until a named person has reviewed it. The assistant prepares, the human decides. ## What it changes on the technical side Once those rules are set, the architecture questions become answerable again: where the service runs, which data actually transits, who holds the keys, what stays in the logs and for how long. We run production for others, in France and in Switzerland, and the discipline is the same as for any sensitive processing: a defined perimeter, named access, segregation, logging, an exit path. An assistant does not invent a new category of risk; it adds one more data egress to map, and that one is triggered by a copy-paste rather than by a flow you designed. The [mistakes we still see in the cloud](/cybersecurite-cloud-les-4-erreurs-que-commettent-encore-80-des-entreprises) show up here unchanged: shared accounts, no segregation, logs nobody reads. ## How to check it this week - Ask who in the company is paying for an AI subscription on a personal card. The answer is rarely the expected one. - Look at whether production logs can be read from an office workstation. If they can, they can be pasted. - Take three real use cases and redo them on anonymised data. If the result holds up, your rule is workable; if it does not, the rule will be worked around, and it is the rule that needs revisiting. The framework of use itself, and the habits that go with it, are covered in [the questions to settle before deploying](/quatre-modes-travail-agent-ia-demander-planifier-executer) and in [what separates two teams given the same tool](/hygiene-de-travail-assistant-ia-quatre-habitudes). On the operations side, see our [cloud managed services](/infogerance) and our [consulting and audit](/conseil). **Should AI assistants be banned for staff?** A blanket ban protects nothing: it pushes usage onto phones and personal accounts, out of all visibility. What protects you is a short list of data that never leaves, company accounts, and a human sign-off before anything goes out of the company. **Which data must never be pasted into an AI assistant?** Anything that identifies a customer or exposes your production: names and contact details, contracts, payment or health data, technical secrets (keys, passwords, configurations), extracts from production logs and databases. In most cases an anonymised version is enough to get the same result. **What should we do if customer data has already been pasted into a consumer tool?** Treat it as an incident, not as misconduct. List what went out and from which account, delete the conversations and the history where the tool allows it, have the data protection officer assess whether notification is required, then close the path that made it possible. Punishing without closing the path guarantees a repeat, only a quieter one. --- # AI assistant: why two teams with the same tool do not get the same result - URL: https://www.premaccess.com/en/hygiene-de-travail-assistant-ia-quatre-habitudes (French original: https://www.premaccess.com/hygiene-de-travail-assistant-ia-quatre-habitudes) - Published: 2026-07-30 · Category: IA Same licence, same machine, very different results. The gap is not the model or the workstation. Where it is really decided, and what it means for a CIO. Two teams, the same tool, the same subscription, equivalent machines. Six months later, one of them has removed several days of manual work per month, the other has mostly consumed budget. We see this gap at almost all of our clients, and it is explained neither by the model chosen nor by the power of the workstations. ## Where the gap is really decided It is decided by usage discipline, that is to say by working habits that settle in within a few days and which, once acquired, are never lost again. That is good news for a CIO: this is not an investment matter, it is a matter of framing and support. It is also bad news if nobody takes care of it, because nothing spontaneously pushes a user to adopt these habits. They are counter-intuitive, and the tool does not impose them. ## The three symptoms that should alert you - **The bill goes up without output following.** A classic sign of unframed usage: requests that are too broad, sessions that drag on, the same work redone every month. - **Nobody knows how to replay what worked.** A good result obtained once and never recorded is a lost result. - **A single member of staff is “the one who knows”.** Know-how does not spread on its own, and you have just created a single point of failure. ## What has to be set down on the organisational side Three decisions, independent of the tool chosen: 1. **Accounts in the company's name, not personal accounts.** That is the condition for then sharing methods between staff, and for not losing the work when someone leaves. 2. **A common place where validated methods land.** Without a shared repository, each person reinvents on their own, and you pay several times over for the same learning. 3. **A regular sharing session.** What one person works out must serve the others. It is the only mechanism that really raises the average level. ## The hardware is not the issue One question always comes up in session: do the workstations need to be re-equipped? In almost every case, no. The workstation accounts for a very small share of the difference in results between two users. The budget is far better placed in the framing and the support of the first few weeks. We install these habits on your own files, over four days on site then two follow-up days. See the [AI training](/formation-ia) and the [technical teams track](/formation-ia/equipes-techniques). **Do workstations need to be re-equipped to use AI in a company?** In almost every case, no. The workstation configuration accounts for a very small share of the difference in results between two users. The budget is better placed in framing usage and in the support of the first few weeks. **Why does the bill go up without any visible gain?** It is the symptom of unframed usage: requests that are too broad, sessions that drag on, and above all the same work redone from scratch every month for want of having recorded what was working. **How can you stop the skill staying with a single person?** Accounts in the company's name rather than personal ones, a common repository where validated methods land, and a regular sharing session. These three decisions are organisational, not technical. --- # AI in the enterprise: why your teams use it badly - URL: https://www.premaccess.com/en/quatre-modes-travail-agent-ia-demander-planifier-executer (French original: https://www.premaccess.com/quatre-modes-travail-agent-ia-demander-planifier-executer) - Published: 2026-07-30 · Category: IA The problem is almost never the tool or the model. It is that nobody has set the framework of use. What it costs, and what to decide before deploying. We run artificial intelligence training courses in companies, for executive committees as well as for technical teams. The finding is the same everywhere: the subscription is paid for, the tool is installed, and the real gain is well below what was expected. Almost never because of the tool. ## What we observe when we arrive - **A single mode of use.** Assistants offer several ways of working, with very different levels of risk. Most users know only one of them, and it is rarely the right one for a subject that involves money or a business system. - **No trace of the reasoning.** The result arrives quickly, it looks correct, and nobody knows by which path it was produced. On a transfer order or a consolidation, that path is precisely what you need to be able to read back. - **Zero capitalisation.** A case that worked in March is redone from scratch in April. Time saved once is never saved twice. - **The skill resting on a single person.** Whoever got started alone becomes one more single point of failure. ## What it actually costs The figures that participants themselves put on the table at the start of a session are systematically higher than management imagined: three days a month of re-entering data at a manufacturer, around an hour a day of bank reconciliation at a group, several hours a week reformalising decisions taken verbally. Those hours already exist. They are simply not counted anywhere. ## The four questions to settle before deploying These are the only ones that really block a general roll-out, and they are not technical: 1. Which data never passes through an external tool. 2. Who is entitled to what, with which access levels. 3. Who validates before an action leaves the company. 4. Who bears the responsibility in the event of an error. As long as they are not settled, a broad deployment is a gamble. Once they are, the rest is execution. ## The principle that never moves The assistant prepares, the human validates, nothing goes out without review. At the start: no automatic sending of email, no direct writing into a business tool. This single rule avoids most of the incidents we see elsewhere. We set this framework and work on your own cases over three days on site, then two days of follow-up. See the [AI training](/formation-ia) and the [leadership team track](/formation-ia/comite-direction). **Why AI training rather than a simple subscription?** Because the subscription says neither what to entrust to the tool, nor how to review what it produces, nor what must never leave the company. It is the framework of use that produces the gain, not the licence. **Which questions have to be settled before generalising?** Four: which data never leaves, who is entitled to what, who validates before an action leaves the company, and who bears the responsibility in the event of an error. They are organisational, not technical. **How do you measure the gain?** By first quantifying the existing workload, role by role, before showing anything at all. Without that starting measurement, no gain is demonstrable afterwards. --- # Cloud cybersecurity: the 4 mistakes 80% of companies still make - URL: https://www.premaccess.com/en/cybersecurite-cloud-les-4-erreurs-que-commettent-encore-80-des-entreprises (French original: https://www.premaccess.com/cybersecurite-cloud-les-4-erreurs-que-commettent-encore-80-des-entreprises) - Published: 2026-03-30 · Category: Cybersécurité The cloud offers unmatched flexibility, but it also multiplies attack surfaces. ![Cybersecurity illustration with monitoring screens and IT security code](/assets/media/191123_0baff8fa1dd544ffb3be22b42c6eb495.webp) The cloud offers unmatched flexibility, but it also multiplies attack surfaces. In 2026, cloud-related security incidents rose by 35% compared with the previous year. The good news: the majority of these incidents are avoidable. ## Mistake no. 1: IAM permissions that are too broad The principle of least privilege remains the foundation of cloud security, and yet it is rarely applied properly. IAM roles with AdministratorAccess permissions handed out widely, access keys that are never rotated, root users used day to day: so many doors left open to intrusions. ## Mistake no. 2: neglecting encryption at rest Encryption in transit (HTTPS) is now standard. But encryption at rest — databases, storage volumes, snapshots — is still neglected by many organisations. In the event of a data breach, it is the difference between a manageable incident and a GDPR disaster. ## Mistake no. 3: no real-time security monitoring Without proactive monitoring, intrusions go unnoticed for weeks, even months. Tools such as AWS CloudTrail, GuardDuty and Security Hub have to be enabled and connected to an alerting system. At Premaccess, our Ultimate BAM offer includes an automated Security Checker and a native audit trail. ## Mistake no. 4: no incident response plan An incident will happen — it is a question of time, not of probability. Companies without a structured response plan take on average 3 times longer to contain a breach. Isolation procedures, crisis communication, immutable backup, tested restore: everything has to be prepared beforehand. ## How Premaccess secures your infrastructure Our approach combines governance, automation and human expertise. With BAM, every deployment automatically follows security best practices. Our SecOps teams provide continuous watch and a fast reaction in the event of a mishap. Contact us at contact@premaccess.com for a security audit of your cloud infrastructure. [Request your cloud security audit](/#contact) --- # FinOps: 5 levers to cut your cloud bill by 40% - URL: https://www.premaccess.com/en/finops-5-leviers-pour-reduire-votre-facture-cloud-de-40 (French original: https://www.premaccess.com/finops-5-leviers-pour-reduire-votre-facture-cloud-de-40) - Published: 2026-03-30 · Category: FinOps The cloud bill has become one of the most sensitive spending items for CIOs. ![Analytics dashboard illustrating cloud cost optimisation and FinOps strategy](/assets/media/191123_a09b9934a5f245ffa009ff3255fce9cf.webp) The cloud bill has become one of the most sensitive spending items for CIOs. In 2026, Gartner estimates that 60% of companies spend more than necessary on their cloud infrastructure. FinOps — a contraction of Finance and Operations — brings a concrete methodology for regaining control. ## 1. Rightsizing: sizing to actual need 80% of cloud instances are oversized. Analysing real metrics (CPU, memory, network) makes it possible to identify under-used resources and resize them. At Premaccess, our BAM platform builds this analysis in continuously. ## 2. Reserved Instances and Savings Plans For stable, predictable workloads, 1- or 3-year commitments offer up to 72% off on-demand pricing. The key is to identify precisely which workloads are eligible and to manage the commitment portfolio over time. ## 3. Spot Instances for flexible workloads AWS Spot instances give access to spare compute capacity at a discount of up to 90%. Ideal for batch processing, machine learning or test environments, they do however require an interruption-tolerant architecture. ## 4. Automated scheduling (Start/Stop) Development and staging environments do not need to run 24/7. With BAM's Scheduling feature, our clients automate the shutdown and restart of their non-production resources — an immediate saving of 65% on those environments. ## 5. Tag governance and per-project visibility Without rigorous tag management, it is impossible to allocate costs to the right projects or teams. BAM automatically enforces tags on every deployment, providing granular visibility of consumption by environment, by client, by service. ## Take action At Premaccess, FinOps is not an option: it is built natively into our managed services offering. Our clients see an average 40% reduction in their cloud bill within the first 3 months. Contact us at contact@premaccess.com for a free audit of your cloud consumption. [Request your free FinOps audit](/#contact) --- # AI and Cloud in 2026: how companies are transforming their infrastructure - URL: https://www.premaccess.com/en/ia-et-cloud-en-2026-comment-les-entreprises-transforment-leurs-infrastructures (French original: https://www.premaccess.com/ia-et-cloud-en-2026-comment-les-entreprises-transforment-leurs-infrastructures) - Published: 2026-03-30 · Category: IA In 2026, AI is an operational lever that needs cloud infrastructure that is elastic, secure and cost-controlled. Here are the key challenges. ![Abstract visualisation of artificial intelligence and cloud networks, illustrating the convergence of AI and cloud infrastructure in 2026](/assets/media/191123_cf36f386bc8945cebca44bde7877db76.webp) In 2026, artificial intelligence is no longer a technological promise: it is a lever of operational transformation for companies of every size. But to take full advantage of it, you still need a cloud infrastructure that is suitable, performant and under control. ## Generative AI is accelerating demand for infrastructure With the rise of language models (LLM), autonomous agents and generative AI applied to business, the needs in compute power, storage and network have exploded. Traditional architectures are no longer enough: what is required are cloud environments that are elastic, secure and cost-optimised. At Premaccess, we have been supporting our clients through this transition for more than 20 years. Our approach rests on three pillars: closeness, trust and technical innovation. ## The 3 key challenges of an AI-ready infrastructure Automatic scalability: AI workloads are unpredictable. A well-designed cloud platform has to adapt to the load in real time, with no manual intervention. Cost control (FinOps): GPU instances and inference services can quickly send the bill through the roof. A rigorous FinOps strategy is essential. Security and compliance: The data processed by AI is often sensitive. Encryption, access governance and GDPR compliance remain priorities. ## BAM: our platform to build, automate and manage Our BAM platform (Build - Automate - Manage) makes it possible to deploy, secure and optimise cloud infrastructures through a single interface. It natively includes FinOps best practices, advanced monitoring and deployment automation — features that are essential for projects involving AI. With BAM, our clients cut their infrastructure costs by up to 50% while gaining in agility and security. ## Ready to accelerate your transformation? Whether you are considering a migration to the cloud, the integration of AI services into your information system, or simply the optimisation of your existing infrastructure, our team is here to listen. Contact us at contact@premaccess.com for an initial conversation with no obligation. [Do you need more information? Contact us!](/#contact) --- # How can a HealthTech choose its HDS host? - URL: https://www.premaccess.com/en/comment-healthtech-choisir-hebergeur-donnees-sante-hds (French original: https://www.premaccess.com/comment-healthtech-choisir-hebergeur-donnees-sante-hds) - Published: 2023-06-08 · Category: À la une Health data: what HDS certification requires in France, what a cloud provider's certificate covers and what remains your responsibility. ![Scientist in a white coat operating a device in a laboratory, surrounded by screens displaying data. An atmosphere of concentration.](/assets/media/191123_ce7682acb4374869b40a250de879c08e.webp) Your start-up is moving into the healthcare sector. Be careful, there are several points to watch with regard to the way you manage data. Health data refers to any information linked to a person’s health, whether physical, mental or social. It can include medical information, clinical data, information on treatments, medical history, test results, medical images, information on allergies, medication taken, diagnoses, etc. Health data is sensitive and confidential information, because it reveals personal details about a person’s health. Consequently, its collection, storage, use and sharing are generally regulated in order to guarantee the confidentiality and the protection of the privacy of individuals. In France, it has to be stored in an environment (traditional host or Cloud Provider) certified HDS (health data hosting). Let us look together at what that involves: ### Table of contents - What is a health data host (HDS)? - What are the obligations of an HDS in France? - About AWS and its HDS certification - How is the confidentiality of health data managed at AWS? - How to achieve compliance easily with the BAM by Premaccess solution [Do you need more information? Contact us!](/#contact) ## What is a health data host (HDS)? A health data host is an entity or a company that provides health data hosting and management services. These are generally companies that specialise in the secure storage and management of medical and health data, in accordance with the regulations and security standards in force. In France, there are several health data hosts that comply with the regulations on the protection of medical data. ## What are the obligations of an HDS in France? In France, a health data host (HDS) is subject to strict legal and regulatory obligations. Here are the main obligations an HDS has to comply with: HDS approval: An HDS must obtain an approval issued by the Agence des Systèmes d’Information Partagés de Santé (ASIP Santé). This approval certifies that the host meets the technical and organisational requirements defined by ASIP Santé. Security and confidentiality : An HDS is required to put in place appropriate security measures to protect the health data it hosts. This includes implementing access controls, cryptography, system monitoring, regular data backup, etc. Data confidentiality must also be guaranteed, preventing any unauthorised access or improper disclosure of the information. Regulatory compliance: An HDS must comply with the regulations in force, in particular the Loi Informatique et Libertés, the General Data Protection Regulation (GDPR), the French law on the protection of health data (the amended “Informatique et Libertés” Act), as well as the recommendations of ASIP Santé. Traceability and auditability: An HDS must put in place traceability and audit mechanisms making it possible to track access to the data, the operations carried out and any security breaches. This information must be retained and be available in the event of an inspection or an audit. Backup and archiving: An HDS must ensure the regular backup of health data and the implementation of a business continuity plan in the event of a disaster. In addition, it is generally responsible for archiving the data in line with the legal retention periods. Staff training: An HDS must train its staff on good security practice, data confidentiality and the legal obligations linked to the protection of health data. These obligations are intended to guarantee the security, the confidentiality and the integrity of the health data hosted, as well as respect for patients’ rights and for data protection regulations. HDS providers are regularly audited to check their compliance with the requirements in force. ![A man in a white shirt uses a smartphone. He is touching the phone's screen. Neutral background, focused mood.](/assets/media/191123_caa0cf0b09f44d32ba50b00cb4acc3e5.webp) ## About AWS and its HDS certification Amazon Web Services (AWS) also offers health data hosting (HDS) services in France through its AWS Healthcare Competency Program. It provides health data hosting and management solutions that comply with the regulations in force. AWS offers a secure and reliable Cloud infrastructure for hosting health data. They provide services such as secure data storage, the implementation of access controls, identity and access management, as well as data encryption features. In addition, AWS provides compliance guarantees, in particular by meeting the requirements of the General Data Protection Regulation (GDPR) and of the ISO 27001 standard. To be compliant with French regulations, AWS offers data centres in France (the AWS Europe Paris region). These data centres are located in France and allow customers to host their health data on French territory, thereby meeting data localisation requirements. AWS adapts to all local data protection recommendations (GDPR in Europe, HIPAA in the USA, etc). ## How is the confidentiality of health data managed at AWS? AWS attaches great importance to data confidentiality, including where health data is concerned. They have put in place specific security measures and practices to guarantee the confidentiality of the data hosted on their platform. Here are some key elements of the management of health data confidentiality at AWS: Access controls: AWS offers robust identity and access management features to control access to health data. This includes assigning role-based access privileges, two-factor authentication, access key management, and the ability to define specific security policies for AWS resources. Data encryption: AWS offers powerful encryption services to protect health data. They allow encryption at rest (storage) and in transit (data transfer) using standard encryption mechanisms, such as AES-256 encryption. AWS also offers key management services to secure the encryption keys. Logical separation of data: AWS uses a shared cloud infrastructure, but they ensure a logical separation of data between customers through virtualisation and isolation mechanisms. This guarantees that one customer’s health data is strictly separated and isolated from the other customers. Regulatory compliance: AWS complies with data protection regulations, in particular the General Data Protection Regulation (GDPR), the HIPAA (Health Insurance Portability and Accountability Act) law in the United States, and other regulations specific to the healthcare sector. AWS provides compliance guarantees and makes audit documents and compliance attestations available. Physical security: AWS puts in place physical security measures to protect the data centres where the data is stored. These measures include video surveillance, controlled access, fire suppression systems, intrusion protection, etc. ## How to achieve compliance easily with the BAM by Premaccess solution? It is important to note that responsibility for the security of health data is shared between AWS as the cloud services provider and the customers who use AWS services. Customers are responsible for configuring the services correctly, for managing access and permissions, and for protecting their applications and systems that use AWS services. Our clients in healthcare ensure their compliance thanks to our expertise in this sector and our BAM Orchestrator solution. Natively, our solution makes it easier to bring infrastructures into compliance, taking standards and regulations into account, particularly in the healthcare sector. [Would you like to find out more? Contact us!](/#contact) **What is HDS certification?** HDS stands for health data hosting. In France, hosting personal health data requires the use of an HDS-certified host. The certification covers specific activities, from the provision of infrastructure through to managed services. **Is AWS HDS certified?** AWS holds HDS certification on the regions concerned. Be careful about the scope, however: the provider's certificate covers its own scope of activity, not your application or the way it is operated on top of it. **Is my host's certification enough?** No. The provider's certificate does not make your platform compliant. Application design, access management, encryption, traceability, the backup policy, and the compliance of operations if they are delegated to a third party all remain your responsibility. **Does my managed services provider need to be HDS certified?** If your managed services provider accesses health data as part of its operations, that activity falls within the scope of the certification. This is a point to check explicitly in the contract, along with the exact scope covered by the certificate. --- # Building a complex serverless architecture based on events - URL: https://www.premaccess.com/en/construire-event-driven-architecture-serverless (French original: https://www.premaccess.com/construire-event-driven-architecture-serverless) - Published: 2023-01-19 · Category: À la une Werner Vogels, CTO of Amazon.com, said it loud and clear in his opening keynote at AWS Re:Invent 2022: “The world is asynchronous. ![Serverless event as text in the centre, surrounded by technology icons and arrows on orange and blue cloud backgrounds. Futuristic mood.](/assets/media/191123_fc4708b9519d44a58e8196e4fc25733b.webp) Werner Vogels, CTO of Amazon.com, said it loud and clear in his opening keynote at AWS Re:Invent 2022: **“The world is asynchronous. The world is event-driven”**. As a global conference about the Cloud, Re:Invent is a crucial annual milestone for selling ideas, showing technology directions and presenting innovations. That is precisely what Dr Vogels did by promoting this asynchronous architecture, the basis of a new generation of cloud computing. But do you know exactly what an event-driven architecture consists of? How it differs from an API-driven architecture? Its benefits? Let us guide you through this asynchronous world! ### Table of contents - Event-driven architecture: a new approach - API-driven architecture vs. event-driven architecture - Challenges of API-driven architecture - The benefits of event-driven architecture in the face of these challenges ## Event-driven architecture: a new approach When it comes to modern application development, an “event-drive architecture” – an architecture driven by events – is becoming more and more the norm, because it makes it much easier to build solutions on the Cloud. It lets you decouple your services, which: 1. increases your developers’ productivity, 2. makes applications easier to debug, 3. removes the bottleneck that occurs when features span different teams, 4. allows teams to move forward more independently. In an event-driven architecture, the way you think about how an application works changes. You see it as a system that reacts to events coming from your application, but also from outside it. In this approach, you focus on the system’s interaction with its environment as the transmission of events. The application receives and creates events. The application’s inputs and the application’s outputs also act as events. ## API-driven architecture vs. event-driven architecture **In API-driven architecture,** the components of an application communicate through API calls. The client sends a request and waits for a response before carrying out the next task. **In an event-driven** architecture, the client generates an event and can immediately move on to its next task. Different parts of the application then respond to the event as needed. ## Challenges of API-driven architecture When starting to build a new application, many developers default to an API-driven architecture. It can tightly integrate components, and those components communicate through synchronous calls. Although an API driven approach is often easier to start with, it can become difficult as your application grows more complex. Here is an example in the context of an e-commerce application. Tight coordination between microservices In a typical e-commerce application that uses a synchronous API, the client makes a request to place an order and the order service sends the request downstream to a billing service. If it succeeds, the order service replies with a success message or a confirmation number. In this initial phase, it is a direct connection between the two services. The challenge arises when you add more services that integrate with the order service. If you add a fulfilment service and a forecasting service, the order service has more responsibilities and more complexity. The order service has to know how to call each service’s API, from the API call structure to the API’s retry semantics. **Error handling and retries** Let us say you add new downstream services for order fulfilment and shipping to the e-commerce application. In the best case, everything works as planned: the order service triggers billing and the payment systems and updates the forecasts. Once the payment has gone through, that triggers fulfilment and packing of the order, then informs the shipping service of the tracking details. However, if the distribution centre cannot find the product because it is out of stock, the distribution service may have to alert the billing service, then cancel the payment or issue a refund. If fulfilment fails, the system that triggers shipping can also fail. The forecasts also have to be updated to reflect the change. This corrective workflow only sets out to resolve one of the many potential “unhappy paths” that can arise in this API-based e-commerce application. **Tight coordination between development teams** In a synchronously integrated application, the teams have to coordinate every new service added to the application. That can slow down each development team’s ability to release new features. Imagine: your team is working on the payment service, and nobody tells you that another team has added a new rewards service. What happens if the fulfilment service errors? Your payment team receives a message and you cancel the payment, but you may not know who handles the retries and the error logic. If the rewards service changes provider and has a new API, and does not tell your team, you may not be aware of the new service. In the end, it can be difficult to coordinate these orchestrations and workflows as the systems become more complex and management adds more services. That is one of the reasons why it can be worth migrating to an event-driven architecture. ## The benefits of event-driven architecture in the face of these challenges Event-driven architecture can help resolve the problems of tight microservice coordination, error handling and retries, and coordination between development teams. **Tight coordination between microservices** In an event-driven architecture, the publisher emits an event, which is acknowledged by the event bus. The event bus routes the events to the subscribers, which process the events with self-contained business logic. There is no direct communication between publishers and subscribers. Decoupled applications allow teams to act more independently. For example, with API-based integration, if your team wants to be told about a change that has happened in another team’s microservice, you may have to ask that team to make an API call to your service. As a result, you may have to take account of authentication and of coordination with the other team on the structure of the API call. This causes back and forth between the teams, which slows down development time. With an event-driven application, you can subscribe to the events sent from your microservice and the event bus (for example, Amazon EventBridge ) takes care of routing the event and handling authentication. **Error handling and retries** Another reason to migrate to an event-based architecture is to handle unpredictable traffic. E-commerce websites such as Amazon.com have varying amounts of traffic depending on the day. Once you place an order, several things happen. First, Amazon checks your payment card to make sure the funds are available. Then Amazon has to pack the goods and load them onto lorries. All of this happens in an Amazon distribution centre. There is no synchronous API call for the Amazon backend to pack and ship the products. Once the system has confirmed your payment, the front end gathers information describing the event and places your account number, your payment card details and what you bought into a packaged event and puts it in the cloud and in a queue. Later, another piece of software removes the event from the queue and starts the packing and shipping. The key point here is that these processes can all run at different rates. **Improving team collaboration** Event-driven architectures encourage the independence of the development team because of the loose coupling between publishers and subscribers. Decoupled applications also allow you to build new features faster. Adding new features or extending existing ones can be simpler with event-driven architectures, because you add new events or modify the ones that already exist. This process removes complexity from your application. ## Conclusion When building a solution on the cloud, the choice between an API-driven architecture and an Event-driven architecture is clearly strategic. Even if the first seems simpler because it is more widely adopted by teams, the second will optimise your development time and your costs in the medium and long term. You should therefore analyse your business objectives so as not to choose a default model that could affect your expansion. ***If you would like advice on this subject, contact the Premaccess team!*** [Contact us](/#contact) --- # MCO in IT: definition, components and benefits - URL: https://www.premaccess.com/en/en-quoi-consiste-maintien-en-condition-operationnelle-mco (French original: https://www.premaccess.com/en-quoi-consiste-maintien-en-condition-operationnelle-mco) - Published: 2022-11-24 · Category: À la une What is MCO in IT? A definition of operational upkeep, what causes outages, the components it covers and how it differs from TMA. ![Finger pushing the first in a row of white dominoes on a wooden table. Dark blue background, blue varnish on the nail.](/assets/media/191123_1c23ee72cca44cf8a924e451bfac8dc7.webp) **MCO (maintien en condition opérationnelle, operational upkeep)** covers every operation that keeps an information system available, secure and fast over time: monitoring, security patches, version upgrades, tested backups and incident handling. It combines preventive maintenance, which avoids outages, and corrective maintenance, which fixes them. **In short:** - **Acronym:** MCO = maintien en condition opérationnelle, French for operational upkeep. - **Scope:** infrastructure, servers, network, applications and websites. - **MCO or TMA:** MCO keeps the system running, TMA (third-party application maintenance) evolves the code. - **MCO contract:** a fixed fee that commits a provider to availability, like our [managed MCO contract](/mco-informatique). ## Operational upkeep: definition Operational upkeep (MCO) brings together all the operations needed to guarantee the constant availability of your information system (IS). So here we are talking about: - infrastructure, server, network - applications, - website… This support is offered by managed services specialists. Two types of maintenance are possible: - Maintenance can be**preventive,** in order to head off possible risks (in terms of security and/or performance). - It can also be **corrective.**In that case, it aims to fix failures that have occurred on your information system. To be avoided as far as possible, “firefighting” mode is never a reassuring solution for your teams. What an [IT MCO contract](/mco-informatique) actually covers, its scope and its billing, is set out on our dedicated page. ## What causes a possible outage of your IS? The causes of malfunctions are many: system overloads, an update that was not applied, hacking, fire, theft of data or of equipment, water damage… ![Miniature figurines dressed as workmen handling a giant Ethernet cable on a colourful motherboard placed on a wooden table.](/assets/media/191123_f9d1b974a3a34720b972dedcd99a2f54.webp) ## The different components of your operational upkeep 1. Management of your infrastructure 2. Management of your network 3. Management of monitoring and observability 4. Management of security 5. Management of your sites and applications 1. Management of your infrastructure In the case of an on-premise infrastructure, the components to be managed are the servers, the storage systems and the equipment that belongs to your company and sits on your premises. In the case of a Cloud infrastructure, your components and resources have to be managed. This may be a private cloud or a public cloud allocated with one of the Cloud providers (AWS, Azure, GCP, Alibaba Cloud). 2. Management of your network Management of your network covers: - your local networks (LAN) - Your remote networks (MAN and VPN) - Your Wifi and office network - Your internet access (WAN) - Your DNS and DHCP - and your equipment 3. Management of monitoring and observability This consists of the proactive monitoring of all your systems. The following actions are put in place: - Installation of monitoring alerts for every perimeter of your IS - Creation of a dashboard showing the overall state of your IS - Setting up of alerts and management of the escalation system - Creation of a monthly report for proactive analysis 4. Management of security The components of your network security are gone through in detail: - Firewall - Proxy - Anti-virus / Anti-spam - Authentication components - GDPR compliance - Pentest & Cyberdefence - 5. Management of your sites and applications This covers the updating and the backup of your solutions. ![Woman in a hard hat and orange vest, smiling and pointing to the right with both hands. White background, cheerful and professional mood.](/assets/media/191123_f3e07fbec8f447cead57b10c4fc0e762.webp) ## Preventive and real-time maintenance Among the preventive measures carried out as part of operational upkeep, we can mention in particular the backup and the replication of your data, as well as its restoration if needed. Real-time maintenance consists of resolving incidents and problems within a window short enough to avoid any unavailability of your services. The objective here will be to organise your teams and business needs so as to plan the necessary changes to your IS in advance. For backup and certain legal obligations, here are the plans offered to you: - **Business Continuity Plan (PCA)**: it ensures the instant recovery of your infrastructure, in the event of a disaster, with no loss of data or of service. - **Disaster Recovery Plan (PRA)** : in the event of a major incident, recovery through your PRA is planned by your partner and your teams, who handle the rebuilding of your IS and the return to service of your applications. However, the recovery time will depend on your IS and involves a temporary interruption of your services. The PCA and the PRA are essential to minimise the financial impact on your business during IT incidents. ## The benefits of MCO By opting for an MCO contract: - You have the assurance that your Information System is always up to date. - You protect yourself against any outages and incidents, with experts overseeing your IS day to day. - You are freed from IT constraints. You therefore increase your internal productivity, and in particular you allow your IT department to be more focused on innovation in your services. - You gain in efficiency by concentrating on your core business. No more time lost on maintenance. - The security of your system is 100% reliable. You no longer have to worry about it. - You make savings, because managed services providers and their DevOps, SecOps & FinOps expertise help you optimise your IS sustainably, on the technical side as much as the financial one. And, this is essential, you stay innovative thanks to our technology watch. MCO frees up time on the operations side; what your teams then do with it stays your decision. The ones that want to automate their own work with AI learn it on their own repository, during the [technical teams track](/formation-ia/equipes-techniques) — one of the three fixed-price [AI training tracks](/formation-ia). ## Conclusion **Getting support in the management of your information system has become a necessity today. Because:** Your information systems increasingly take the form of complex structures. Maintaining the IT system demands technical skills and expertise that are constantly evolving. Outsourcing your MCO lets you focus on your professional priorities while your provider takes care of the proper management, the maintenance, the operation, the security and the optimisation of your information system. [An MCO project? Let's discuss it together!](/#contact) ## Looking for an MCO contract for your infrastructure? We provide operational upkeep on AWS, Azure, Google Cloud and Alibaba Cloud: updates, patches, backups, 24/7 monitoring and disaster recovery. [See our MCO offer on a monthly contract](/mco-informatique) Also read: [what technical debt is and how to keep it under control](/qu-est-ce-que-dette-technique-comment-la-maitriser), the most frequent cause of an expensive MCO. **What does MCO mean in IT?** MCO is the acronym for operational upkeep. It refers to all the activities that keep a system in working order over time: security patches, version upgrades, backups, monitoring and incident handling. **What is the difference between MCO and TMA?** MCO covers the infrastructure and the technical components. TMA, third-party application maintenance, covers the business code of the application. The two are complementary, and the boundary between the two scopes is the point to clarify before signing. **What is the difference between preventive and corrective maintenance?** Preventive maintenance acts before the outage: threshold monitoring, security patches, tested backups. Corrective maintenance fixes an outage that has already happened. Well-run MCO shrinks the corrective share, the firefighting mode that never reassures a team. **Which components does MCO cover?** Five families: infrastructure (servers, storage, cloud resources), the network (LAN, VPN, internet access, DNS), monitoring and observability, security (firewall, authentication, GDPR compliance) and your sites and applications, with their updates and backups. **Who handles the MCO of an information system?** An in-house operations team, or a managed services provider under an MCO contract. What such a contract covers, its scope and its billing model are set out on our IT MCO page. --- # On-premise to Cloud migration: our advice for getting started - URL: https://www.premaccess.com/en/migration-on-premise-vers-cloud-conseils (French original: https://www.premaccess.com/migration-on-premise-vers-cloud-conseils) - Published: 2022-06-22 · Category: À la une Moving off your on-site servers to the cloud: appoint an owner, pick a strategy per application and cut production over without downtime. ![Flock of pink birds flying in V formation in a clear sky. The feathers reflect a bright pink hue. Serene atmosphere.](/assets/media/191123_555a5cb6aeb24012b2a5197fb593ea95.webp) At Premaccess, we are increasingly approached by companies wishing to migrate their on-premise infrastructure and applications to the Cloud. To help them, and to help you understand what is at stake in this project, which is necessary to boost a business, we offer a focus on 3 essential points: Looking for a partner to run the project? Our [cloud migration](/migration-cloud) offer details the method, the paths and the funding available. ### Table of contents - Definition: what is migration to the Cloud? - What are the benefits of migrating to the Cloud? - How do you carry out a Cloud migration? ## Definition: what is migration to the Cloud? On-premise to Cloud migration consists in moving your digital assets (data, applications, workloads, business components) from on-site infrastructure to the Cloud. “On premise” means that you use physical servers and software on which you run your databases, your applications and your workloads. By “Cloud”, we mean all the services (both the underlying hardware and the software to run your services) made available to you over the Internet by Cloud service providers (AWS, Google Cloud Platform, Azure for example). During a [migration to the Cloud](/migration-cloud), a change of paradigm takes place: you are no longer in control of the underlying technology stack, you entrust it to a third party. ## What are the benefits of migrating to the Cloud? These benefits are numerous. Here are the 4 main ones: **Elasticity:** Public Cloud providers allow you to scale up your computing, memory and storage resources quickly according to your needs. This is what is called autoscaling. **Transparent cost of services:** Your organisation pays only for the resources actually used: computing, network, storage. It can therefore plan costs according to the growth of the business and the needs of your [clients](/business-case). **Fault tolerance, reliability and resilience:** Cloud infrastructure is built with state-of-the-art technology. If a physical machine dies, another one replaces it without affecting your operations. Public Cloud providers plan for the worst. They have several data centres around the world intended to reduce the adverse effects of possible failures on your technical platform. **Agility and flexibility:** The Cloud is accessible from anywhere in the world. You therefore benefit from an unlimited ability to distribute your services as close as possible to your clients. ![View of a city at dusk under a pink sky, with drawings of clouds and Wi-Fi symbols. Illuminated skyscrapers, futuristic mood.](/assets/media/191123_8f0bdd2ec2b341dbb5abcf8b6022a490.webp) ## How do you carry out a [Cloud migration](/migration-cloud)? Any migration calls for organisation and thought, because it touches the very heart of your company. For such a project, we strongly advise you to surround yourself with a partner of choice such as Premaccess. However, to give you an overview of the work to be carried out during a migration, here are the key steps on which your company will be called upon. [Contact us](/#contact) ### **Key step 1: Appoint a lead for your migration** Before starting your migration to the Cloud, appoint an architect to lead this project. The architect is a system-architect-level position, responsible for planning and delivering every aspect of the migration. Among other things, they will have to define the migration and deployment strategies, determine the priorities and the mechanisms for switching over to production. In the course of a large migration project, many technical plans have to be drawn up. Having an architect responsible for all these aspects is a priority for a successful project. ### **Key step 2: Define a migration strategy for your applications** Several migration methods are possible. You will adopt one of them according to your level of Cloud maturity and to the involvement you wish to put into it. Each of them: - will take you more or less time, - will generate a cost when it is put in place, - will or will not allow you to optimise your budgets over the medium and long term. ### Method 1. “Lift and shift” Consists in migrating an application from one environment to another without carrying out any redesign or code modification. This method is the most widely used today. It is simple and quick to carry out. That said, “lift and shift” migrations do not benefit from native Cloud features such as elasticity.This method can prove costly over the medium and long term. ### **Method 2. “Replatforming”** Aims to move your applications to the Cloud with a small upgrade, by using a Cloud-managed database offering or by adding auto-scaling (elasticity of certain applications) enabled by automation. This approach offers a solid compromise between “lift and shift” and “refactoring”. It makes it possible to take advantage of the basic Cloud features and to optimise costs, without committing a high level of resources. ### Method 3. “Refactoring” Involves a more advanced process, requiring you to rethink the architecture and the code of your existing applications in order to optimise native Cloud features. This approach is the longest to put in place. But it will allow you to reduce the cost of using Cloud services immediately.It will also bring you flexibility and faster access to the new innovative services provided by Cloud Providers, such as Artificial Intelligence, Machine Learning or the Internet of Things. ![Two computers exchanging files and documents between two servers, on a light blue background with cogs. Technological mood.](/assets/media/191123_558f3ea9774d407487f6fd26e2293b3a.webp) ### **Key step 3: Choose a single Cloud or opt for multicloud** At the start of this project, you will have to choose between one or several Cloud providers. Do you want to migrate your applications so that they run in an optimised way on a single environment, or on several Cloud providers? If you would like advice on this subject, [contact us](/#contact)! ### Key step 4: Create a data migration plan Data migration is one of the most delicate steps. The location of your data can have a significant impact on the performance of your application, here you have to choose the target Cloud provider’s services carefully according to the different types of data (media, code, applications, logs and databases). Examples – Data migration options: - Using a two-way synchronisation mechanism between your on-site databases and the Cloud. Once you have finished your migration to the Cloud, you will be able to delete them on site. - For an on-site database where only one-way synchronisation is possible, we suggest you use DMS-type services to send the data to your new Cloud-based database server.When you are ready, disable your applications’ access to the on-site version so that the Cloud-based version becomes the main database. For the migration of other data, we advise you to use another type of data migration service, such as those available from Amazon Web Services: - AWS Migration Hub - AWS Storage Gateway - AWS Direct Connect - AWS Data Pipeline or Data Brew - Amazon S3… etc Do not underestimate the complexity and the importance of planning the data migration. Failing to pay particular attention to your data migration plan before starting a move to the Cloud can lead to the failure of your project. Your migration architect must be closely involved in this planning process. You can entrust this to a partner such as Premaccess. ![A man jumping between two cliffs of the Grand Canyon, wearing a red shirt and a bag. Clear blue sky and desert landscape.](/assets/media/191123_592929bf8f6546749fb1b7e0635d44a6.webp) ### Key step 5: Switch production over Before migrating your applications to the Cloud, it is recommended that you put a cutover strategy in place. Objective: minimise downtime when moving from one environment to another. We present the two main ones here: ### The “Big Bang” ### As its name suggests, the “big bang” method migrates entire and/or large parts of your platform in one go. This method generally causes production outages that have to be calculated on the basis of long iteration cycles and dry runs in order to minimise the impact and the interruption of your services. Assuming a minimal risk of failures, rollbacks may be impossible or impractical. As a result, the “Big Bang” method is not suitable for all types of applications. A choice has to be made between strategic realities and technical possibilities. ### The progressive cutover The progressive cutover is preferable in certain cases. It minimises or even eliminates downtime when switching your production over. This method will allow you to roll back more easily, without an outage. However, this method cannot be used for all the technologies available on the market. ## Conclusion These are the 5 main steps in a migration to the Cloud. To these are added, of course, the best practices in terms of security and the waves of tests to be carried out to make sure that everything works properly. Finally, one last tip: we are sharing Cloud migration tools with you here. Each Cloud provider offers several tools and services to make your migrations easier. AWS presents several of them in the link below. Feel free to consult it: [AWS whitepaper: migration services](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/migration-services.html) As you will have understood: an on-premise to Cloud migration project cannot be improvised! It calls for thought, organisation and methodology. If you wish to start such a project, [**do not hesitate to get in touch with us here**](/#contact). Our teams will advise you and support you step by step on this demanding project, which may seem complex. [Contact us](/#contact) **Do applications have to be rewritten in order to migrate?** No, not systematically. Rehosting without modification makes it possible to leave a datacenter quickly, with optimisation coming later. Rewriting first lengthens the project and combines two risks at the same time. **How do you migrate without service interruption?** Through a progressive cutover: replication of the data to the target, running in parallel, verification, then switching the traffic over with a rollback still possible. The rule is that rollback remains possible until the last moment. **Which applications should a migration start with?** The least coupled and least critical ones: they validate the target, the tooling and the cutover procedure without exposing the core of the business. The most intertwined applications go last, with a team that has already done it. --- # What is technical debt? How can you keep it under control? - URL: https://www.premaccess.com/en/qu-est-ce-que-dette-technique-comment-la-maitriser (French original: https://www.premaccess.com/qu-est-ce-que-dette-technique-comment-la-maitriser) - Published: 2022-05-12 · Category: À la une Technical debt: definition, concrete examples, causes, how to measure and audit it, then reduce it without freezing your product changes. ![Grey calculator on a bright orange background. The keys are red, blue and grey with symbols and digits. Neutral mood.](/assets/media/191123_b66c1bea41734ba3b1f9526ee9434030.webp) **In short:** technical debt is the future cost of the shortcuts taken in development and operations: unrefactored code, missing tests, dependencies out of support, infrastructure configured by hand. Like financial debt, it accrues interest: every change becomes slower, more expensive and riskier. ## Technical debt: a definition A software development project often includes a software design, formalised or not. Writing the code, if it follows best practice, ensures the consistency of the project and makes its maintenance easier: - **corrective:** fixing software bugs, - **evolutionary:** adding new features to the software. Technical debt arises when best practice has not been followed while writing the code of your solution. In that case, a neglected software design will create future costs to be repaid in the form of additional development time, and increasingly frequent bugs. Technical debt should therefore be settled as early as possible to avoid tying up your teams unnecessarily. ## Technical debt can be intentional or not - **Unintentional technical debt is due to defects:** the design not being followed, coding rules not being followed, and so on. There is no benefit to be gained from this type of debt. - **Intentional technical debt is calculated in advance.** Since favouring design quality increases the workload, the developers of a piece of software may choose to sacrifice quality in order to gain a benefit. For example, if a new version of the software has to be delivered quickly, sticking to the ideal design may jeopardise delivery of the product. In this situation, the objective (the release of the new version) takes priority. The intentionality of technical debt would therefore be to take on short-term debt in order to support the long-term evolution of the project. The key would then be to repay that debt quickly, once the objective has been reached, to avoid interest accumulating. [Would you like advice and support on this subject? Contact us](/#contact) ## Concrete examples of technical debt Technical debt is not limited to code. In the systems we take over for operations, it almost always takes one of these forms: - **Dependencies out of support:** a version of PHP, Java, Node.js or a database engine that no longer receives security patches. - **No automated tests:** every change is checked by hand, so slowly, and regressions reach production. - **Duplicated code:** the same business rule is copied in several places and fixed in only one. - **Infrastructure configured by hand:** servers nobody can rebuild identically, for lack of infrastructure as code. - **Manual deployments:** a release that depends on one person and an unwritten procedure. - **Missing documentation:** the knowledge lives in the heads of developers who eventually leave. ## The causes of technical debt When developing a solution, you can anticipate many things and spend a large part of your time planning your project or perfecting your code. But there are always a few things beyond your control that can lead to technical debt. These are: - **time pressure:** development teams often release applications that are not complete because of the pressure to deliver the product within a limited timeframe. Development teams may even cut performance and quality in order to reach the market faster. - **constant change:** even complete applications finished on time can be obsolete by the time they reach the market. Ever-growing customer expectations, the rise of new market opportunities, new cyberattacks and developer turnover create permanent challenges for IT managers. - **obsolete technology:** modern application development generally involves several coding languages, frameworks and libraries, which may become obsolete or unsupported each year. Today’s Python could be tomorrow’s Visual Basic. ![Growing stacks of coins topped with green plants, a jar full of coins on the right. Blurred natural background, an atmosphere of prosperity.](/assets/media/191123_0743fb5d82d944d98cbb1afefc856ffc.webp) ## The damaging consequences of technical debt Low-code specialist OutSystems surveyed many IT leaders around the world about technical debt, its cost, its origins and the solutions considered to address it. More than 500 of them concede that this debt is a problem they have to fight against on a daily basis. The results of this survey are eye-opening: - Companies are currently said to be losing 6 000 € per second to maintain outdated lines of code. - On average, companies spend 28% of their IT budget fighting technical debt. Whereas barely 33% of that budget is allocated to innovation. - The larger a company grows, the more this problem intensifies: small and medium-sized enterprises spend 27% of their IT budget on technical debt. Large companies spend 41% of their IT budget on technical debt. - 51% of large companies state that technical debt harms their conquest of new markets. - 64% state that it will have a major impact on their future business. - 69% state that it limits their capacity to innovate. - 32% say that one of their biggest concerns is errors that only come to light after release to market. ## What type of technical debt is your company facing? In the quest for speed, is technical debt always harmful? To answer this question, it is useful to use Martin Fowler’s “technical debt quadrant”. This quadrant categorises the type of technical debt according to intent and context. - **Prudent and deliberate:** when the team knows it is accumulating interest. Yet it prefers to face the consequences later. This decision is acceptable if the stakes are low enough or if the gain from an earlier release outweighs the costs of the technical debt. - **Reckless and deliberate:** when the team may know the consequences and could avoid them, but still favours speed over quality. - **Prudent and inadvertent:** when the team learns how the solution should have been implemented after the implementation. - **Reckless and inadvertent:** when the team lacks the experience and blindly implements the solution. The team does not realise it is getting itself into a gigantic mess. The left-hand side of this quadrant must be avoided at all costs. ## Finding the right balance between speed and quality Software quality and performance are paramount to a good user experience. Speed, for its part, is essential to reaching business objectives on time. Managing technical debt therefore requires a balance between quality and speed. The best way to manage technical debt is to work on it continuously and to allow your engineering team to: - see codebase problems, - report and log those problems, - prioritise and resolve them. In this case, you therefore need to: - Make it easier for your team to track and visualise technical debt. - Have a space through which your team can discuss these codebase problems. - Integrate your technology debt work into your existing workflow. ## How to measure and audit technical debt Debt you do not measure does not get repaid. A few indicators are enough to make it visible and track how it evolves: - **Static code analysis:** duplication, complexity and defects reported by a tool such as SonarQube, tracked over time rather than as an absolute value. - **Test coverage:** the share of the code checked automatically on every change. - **Outdated dependencies:** the number of libraries, frameworks and engines behind on version or out of support. - **Lead time:** the time from a request to its release, and the share of releases that cause an incident. - **Share of fixing:** the time spent fixing rather than evolving the product. A technical debt audit cross-checks these measures with the architecture and operations: an inventory of components and their versions, a review of code and tests, a review of infrastructure and deployments, then an action plan prioritised by risk and cost. On the infrastructure side, our [Well-Architected cloud audit](/audit-cloud) covers security, cost, reliability and performance. ## Rewrite or gradual repayment? Faced with heavy debt, the temptation is to rewrite everything. It is rarely the best choice: a full rewrite freezes changes for months and builds its own debt, under the same deadline pressure. Gradual repayment tackles what blocks the most first, component by component, without stopping the product. A rewrite is justified when the technical foundation is no longer maintained at all, when every change costs more than rewriting the component concerned, or when the architecture prevents an essential business need. Even then, replacing the system piece by piece beats a single cutover. ## How to reduce technical debt Reducing technical debt is not about rewriting everything, but about making it visible and repaying it regularly: - **Audit what exists** — a [Well-Architected cloud audit](/audit-cloud) maps security, cost and reliability risks and prioritises the work to be done. - **Refactor continuously** — build debt repayment into every iteration rather than into a “big project” that is put off indefinitely. - **Automate** — automated tests, CI/CD and infrastructure as code reduce future debt with every release. - **Maintain operational upkeep** — [MCO](/mco-informatique) (updates, patches, monitoring) stops debt from building up through obsolescence. - **Get support** — an outside view from [consulting and architecture](/conseil) helps in arbitrating between speed and quality. ## Conclusion If technical debt is not kept under control, it can grow very quickly and considerably affect your company’s budget. The pressure put on teams to produce solutions ever faster, the regular turnover of developers within teams, or the obsolescence of development languages and frameworks are the primary causes of this technical debt. But be careful, not all technical debt is necessarily harmful. It is up to you to work out which type of debt you are facing, thanks to Martin Fowler’s “quadrant”. Finally, to keep it under control, you will need to find the right middle ground between speed and quality. Surround yourself with experts to do so. ***The***[***Premaccess***](/)***team advises many companies on this subject. Do not hesitate to contact us.*** [Would you like advice and support on this subject? Contact us](/#contact) **What is technical debt in IT?** Technical debt refers to the future cost of the shortcuts taken during development: code that has not been refactored, missing tests, obsolete dependencies or a dated architecture. Like a financial debt, it generates interest — every change becomes slower and riskier. **How do you measure technical debt?** It is assessed through static code analysis (SonarQube, linters), test coverage, average delivery time, the rate of bugs in production and an architecture audit. A Well-Architected cloud audit gives a structured view of it. **How do you reduce technical debt?** Through continuous refactoring, adding automated tests, updating dependencies, automation (CI/CD, infrastructure as code) and a dedicated recurring budget. The goal is not zero debt, but debt that is controlled and visible. **Should all technical debt be eliminated?** No. Intentional, tracked debt can be a strategic choice in order to deliver quickly. The risk comes from invisible, unmanaged debt: the point is to make it visible, prioritised and repaid regularly. **Do you need a full rewrite to clear technical debt?** Rarely. A full rewrite freezes changes for months and builds new debt under the same deadline pressure. It is better to repay component by component, starting with what blocks the most, and keep rewriting for components whose foundation is no longer maintained. **What causes technical debt?** Deadline pressure, which ships work before it is finished; constant change in needs and technology, which dates code that was complete; and missing shared rules: no automated tests, no code review, infrastructure configured by hand. **What are the types of technical debt?** It is intentional when the team accepts a shortcut to ship faster and plans to repay it. It is unintentional when it comes from poor workmanship or missing skills. It hits the code, but also dependencies, infrastructure, deployments and documentation. --- # From relational database to single-table architecture with DynamoDB - URL: https://www.premaccess.com/en/architecture-monotable-avec-dynamodb (French original: https://www.premaccess.com/architecture-monotable-avec-dynamodb) - Published: 2022-01-27 · Category: À la une Amazon DynamoDB is a high-performance NoSQL database devised by Werner Vogel (Amazon’s CTO). ![](/assets/media/191123_fd968029ea68468cbbfe2b31c1c0992c.webp) **Amazon DynamoDB is a high-performance NoSQL database devised by Werner Vogel (Amazon’s CTO). It provides data storage for a great many applications. Unlike traditional SQL databases, this service does not use table joins. That forces you to rethink how you record your entities. We then speak of “single table”, or single-table, design.** **Data modelling with DynamoDB can be tricky for anyone used to relational databases. Let us look together at what a single-table database architecture is, the steps to follow to build one, its advantages and its drawbacks.** ### Table of contents - Definition: what is a single-table database architecture? - How do you design a single-table database architecture? - The advantages of single-table design - Drawbacks of a single-table design ## Definition: what is a single-table database architecture? Single-table design is a data modelling technique used to represent relational data structures in a single NoSQL table. It is about organising all your data intelligently in one single table (and no longer one table per entity!) and using a primary key, a sort key and indexes to link the entities to one another and access them quickly and efficiently. ## How do you design a single-table database architecture? Planning is essential in this type of design. You need to know what your data is, how it relates to one another and, more importantly, what your access patterns (design pattern) are – they dictate how you must organise your items. 1. Here are the steps to follow to create one: 2. Create the ERDs (Entity / Relationship Diagram) 3. Determine the access patterns (design pattern) 4. Define the key structures (leading keys) 5. Define the physical indexes (primary key, sort key, GSI/LSI) 6. Define the key design strategies 7. Define the useful entity relationship strategies To understand this concept, let us look at some modelling in relational databases, then see together why you have to model differently in DynamoDB. [Let’s discuss your project together!](/#contact) ### Background on SQL modelling and joins With relational databases, you generally normalise your data by creating a table for each entity type in your application. For example, if you are building an application for online sales, you will have a table for customers and a table for orders. ![](/assets/media/191123_bb198fb322bf4d5992ccf099e786f62b.webp) Each order belongs to a given customer and you use foreign keys to reference a record in one table from a record in another. These foreign keys act as pointers – if I need more information about a customer who placed a particular order, I can follow the foreign key reference to retrieve items about that customer. ![](/assets/media/191123_b23d0aa12a644038b4f64505f1cc235d.webp) To follow these pointers, SQL, the language used to query relational databases, has a concept of joins. Joins let you combine records from two or more tables at read time. ### The problem of missing joins in DynamoDB Convenient though they are, SQL joins are also expensive. They require: - scanning large portions of several tables in your relational database, - comparing different values and returning a result set. Joins in SQL are limited and hardly scalable. The larger the volume of data, the more performance drops. DynamoDB works around the problem by removing the ability to use them. In our example below, we want to obtain both a customer record and all of that customer’s orders. In this case, many developers will apply relational design patterns with DynamoDB even though they do not have relational tools such as joins. And since there are no joins, they will have to run several queries to retrieve both the orders and the customer record. ![](/assets/media/191123_a8f43e8a54f44f30b747e7728c65d513.webp) This can cause significant problems in your application, because you will then be running several cascading queries. As your application grows, it could lose performance and become slower and slower. ### The solution: group your data into collections using composite keys So how do you get fast, consistent performance from DynamoDB without making several queries to your database? By grouping your data using item collections. An item collection in DynamoDB refers to all the items in a table or an index that share a partition key. In the example below, we have a DynamoDB table that contains actors and the films they have appeared in. *The partition key is the actor’s name, and the sort key is the film’s name.* ![](/assets/media/191123_a6a282abc1e948a0b2ea762c3a1cd498.webp) You can see that there are two items for “Tom Hanks” – “Cast Away” and “Toy Story”. As they have the same partition key “Tom Hanks”, they sit in the same item collection. You can use DynamoDB’s “Query” API to read several items with the same partition key. So if you need to retrieve several heterogeneous items in a single query, you organise those items so that they sit in the same item collection. In the case of an online sales application, the partition key is the user’s name and the sort key is the order record. For this to be possible in a single query, we make sure that all the order records exist in the same collection as the user record they belong to. ![](/assets/media/191123_5dde19feccf940919224deb449874f39.webp) Now, when we want to retrieve the user and the orders, we can do it in a single query without needing an expensive join operation: ![](/assets/media/191123_d1cd135f46394725a9a73f120e3ea9f5.webp) That is the whole point of single-table design: organising your table so that your access patterns can be handled with as few queries to DynamoDB as possible, ideally one. ## The advantages of single-table design This type of single-table architecture lets you: - access data more quickly, in one or two queries. - minimise the number of tables you have to manage. - avoid the operational overheads (monitoring, backup etc …) seen in a classic design comprising several tables. - make savings: if you have one or two entity types in your single table that are accessed far more frequently than the others, you can hide part of the extra capacity for the less frequently accessed items in the buffer of the other items. - benefit from the near-infinite scaling that DynamoDB provides. - improve your solution’s performance by making a single request to retrieve all the items you need. ## Drawbacks of a single-table design There are three drawbacks to single-table design in DynamoDB: ### The steep learning curve of single-table design A single, overloaded DynamoDB table can look really strange at first sight compared with the clean, normalised tables of your relational database. It is hard to unlearn all the lessons you have learned over the years from relational data modelling. ### The inflexibility of adding new access patterns (access pattern) A second difficulty with DynamoDB is fitting new access patterns into a single-table design. When modelling a single-table design in DynamoDB, you start from your access patterns. Think carefully: how will you access your data? Then model your table carefully to satisfy those access patterns. You organise your items into collections so that each access pattern can be handled with as few queries as possible, ideally a single query. ### The difficulty of exporting your tables for analysis DynamoDB is designed for OLTP use cases — high-speed data access where you work on a few records at a time. But users also need OLAP access patterns – large analytical queries over the whole data set to find popular items, or the number of orders per day, or other information. DynamoDB is not good at OLAP queries. That is deliberate. DynamoDB focuses on the ultra-performance of OLTP queries and wants you to use other databases purpose-built for OLAP. To do that, you will have to move your data from DynamoDB to another system, for example using DynamodbStream to put the data into S3 (then queried via Athena) or elasticsearch. If you have a single-table design, it can be hard to put it into the right format for an analytics (OLAP) system. ### Conclusion Single-table database architecture goes hand in hand with DynamoDB. We recommend it if you manage a large volume of data that you need to access very quickly. Beyond ten entities or so, it can be a great help. Below that, be careful: you risk building an over-engineered contraption for very little. We also recommend putting it in place at the initialisation of the project, on all or part of your application. Example: it is perfectly possible to develop single-table for the basket part of an e-commerce site, and to use relational databases for everything else. **Hence the importance of planning the design of this kind of database architecture properly before embarking on it.** By following all this information, you can now create your single-table database on DynamoDB. Once you have modelled your table, you will put it into action and write the code to implement it. Your application will then be able to scale indefinitely without performance degradation. If you would like advice and support on this subject, do not hesitate to contact the Premaccess team. As AWS experts, they will support you step by step in delivering this project. [Contact us](/#contact) **Sources used in writing this article:** - [Creating a single-table design with Amazon DynamoDB](https://aws.amazon.com/fr/blogs/compute/creating-a-single-table-design-with-amazon-dynamodb/) - [The What, Why, and When of Single-Table Design with DynamoDB](https://www.alexdebrie.com/posts/dynamodb-single-table/) - [Trek10: DynamoDB single-table relational modeling](https://www.trek10.com/blog/dynamodb-single-table-relational-modeling) - [Dynobase: DynamoDB single-table design](https://dynobase.dev/dynamodb-single-table-design/) - [DynamoDB and Single-Table Design](https://fullstackdeveloper.tips/so-how-do-you-start-with-dynamodb/) - [SenseDeep: DynamoDB single-table design](https://www.sensedeep.com/blog/posts/2021/dynamodb-singletable-design.html) --- # “AWS messaging solutions”: which to choose between SQS, SNS, EventBridge, Kinesis Data Streams / Firehose? - URL: https://www.premaccess.com/en/aws-messaging-solutions-sqs-sns-eventbridge-kinesis-data-streams-firehose (French original: https://www.premaccess.com/aws-messaging-solutions-sqs-sns-eventbridge-kinesis-data-streams-firehose) - Published: 2021-06-03 · Category: À la une SQS, SNS, EventBridge, Kinesis Data Streams or Firehose: what each AWS messaging service is for and which to choose for your use case. ![](/assets/media/191123_cd7a6d63347246aab69629ebcff3a2d7.webp) **In a serverless architecture, “Messaging services” are needed to let solutions (applications, software) communicate with each other and exchange data. On AWS, several of these services are available. We present the 4 main ones: Amazon Simple Queue service (SQS), Amazon Simple Notification Service (SNS), Amazon EventBridge and Kinesis Data Streams / Firehose. A closer look at the type of information transfer offered (queue, notification, event bus & streams) and at how they work.** ### Table of contents - “Messaging services”: what are they for on AWS? - When should you use Amazon Simple Queue Service (SQS)? - When should you use Amazon EventBridge? - When should you use Amazon Kinesis Data Streams / Firehose? ## **“Messaging services”: what are they for on AWS?** On the AWS cloud, “Messaging services” allow different systems (software, applications and end devices) to communicate and exchange information, even if they do not use the same programming languages and are installed on different platforms. These services are essential in a serverless architecture. Indeed, most of them use a combination of different AWS services, microservices and AWS Lambda functions. Without these solutions, they cannot pass each other the data needed for production. On Amazon Web Services there are several of them, each with very specific features. Before choosing one, we advise you to take stock of your needs and your objectives. What type of information transfer do you want to put in place between your different systems? In this article, we invite you to discover the**four information transfer models most used by developers**: queues, notifications, and event buses. On AWS, these models are provided respectively by****the services**Amazon SQS, Amazon SNS, Amazon EventBridge and Kinesis Data Streams / Firehose**. These 4 services are fully managed and highly available, so there is no infrastructure to manage. They let you publish messages via the AWS SDK and call functions as targets. ## **When should you use Amazon Simple Queue Service (SQS)?** ![](/assets/media/191123_02aff77678ab4d1da206e4b46a484421.webp) ### **Type of information transfer: communication to applications or people** SNS is a messaging service useful for application-to-application (A2A) and application-to-person (A2P) communication. ### **One-to-many relationship** This service offers a one-to-many relationship. A message can therefore be sent to several consumers. This behaviour is called fan-out. An SNS topic can have up to 12 500 000 subscribers, offering highly scalable broadcast capabilities. Using Amazon SNS topics, your publishing systems can send messages to subscriber systems, including Amazon SQS queues, AWS Lambda functions and HTTP/S endpoints, for parallel processing, not forgetting Amazon Kinesis Data Firehose. ### **Push service** The A2P feature lets you send messages to users at scale via SMS, Mobile Push and email. Unlike SQS, SNS does not retain messages, so if there are no subscribers for a topic, the message is discarded. **How to filter messages published to topics with**[**Amazon Simple Notification Service (SNS)**](https://aws.amazon.com/fr/sns/)**and**[**Amazon Simple Queue Service (SQS)**](https://aws.amazon.com/fr/sqs/)**|**[AWS tutorial: filter messages published to SNS topics](https://aws.amazon.com/fr/getting-started/hands-on/filter-messages-published-to-topics/) **To find out more |** [Amazon SNS](https://aws.amazon.com/fr/sns/) ## **When should you use Amazon EventBridge?** ![](/assets/media/191123_39e02896e0ce408985249b8e0c8e35cf.webp) ### **Type of information transfer: event bus** EventBridge connects AWS services, software as a service (SaaS) providers and your own applications using events. An event is a signal indicating that the state of a system has changed, for example the change of state of a customer support ticket. Customers can integrate microservices, SaaS applications and custom applications into their own AWS applications as event sources that publish events to an event bus. ### **Event-based architectures** EventBridge simplifies the process of building event-based architectures. You can filter and transform incoming messages at the service level and route events to several targets, including Lambda functions. ### **Writing custom code** EventBridge simplifies the connection of applications. You can add, filter, transform and deliver events without writing custom code. The EventBridge schema registry stores a collection of event schemas that are easy to find and lets you download code bindings for those schemas into your IDE in order to represent the event as a strongly typed object in your code. **How to create an Amazon EventBridge schema** ****[Creating an event schema in Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-create.html) **To find out more |** [Amazon EventBridge](https://aws.amazon.com/fr/eventbridge/) ## **When should you use Amazon Kinesis Data Streams / Firehose?** ![](/assets/media/191123_6d984b91dfe94f71ae56907e8dc317cb.webp) ### **Type of information transfer: data streams** Amazon Kinesis makes it easier to collect, process and analyse streaming data in real time, in order to obtain strategic information quickly and to react quickly. With Amazon Kinesis, you can ingest data in real time, analyse it as it is received and react instantly instead of waiting for all the data to be collected before starting to process it. ### **2 types of data stream** - **Kinesis Data Streams** is a real-time data streaming service, able to capture continuously several gigabytes of data per second from hundreds of thousands of sources (website clicks, database event streams, financial transactions, social media feeds, IT logs, location events). The collected data is available within milliseconds to enable the use of real-time analytics such as real-time dashboards, real-time anomaly detection, dynamic pricing - **Kinesis Data Firehose** is the simplest way to capture, transform and load data streams into AWS data stores for near real-time analytics with existing business intelligence tools. It can capture, transform and deliver streaming data to Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, generic HTTP endpoints and service providers such as Datadog, New Relic, MongoDB and Splunk. It can also batch, compress, transform and encrypt your data streams before loading them, which reduces the storage space used and strengthens security.To find out more | [Amazon Kinesis](https://aws.amazon.com/fr/kinesis/)Choosing the right messaging service is not always simple! In some cases, you will need to combine two of these services or more. ***Do not hesitate to consult the AWS documentation for each service.*** [And if you would like support in setting them up, contact us!](/#contact) **What is the difference between SQS and SNS?** SQS is a queue: a message is consumed by one reader, which decouples a producer from a consumer and absorbs peaks. SNS is a broadcast service: a message is sent to all subscribers at the same time. A queue to process, broadcast to notify. **When should you use EventBridge rather than SNS?** When routing depends on the content of the message. EventBridge filters and routes according to rules based on the structure of the event, and connects natively to the events of AWS services and to third-party applications. SNS broadcasts without fine-grained routing logic. **When should you use Kinesis Data Streams?** When you need an ordered, replayable stream, read by several independent consumers that progress at their own pace. That is the case for telemetry, clickstreams and any analytical processing that must be able to be re-run over history. **What is the difference between Kinesis Data Streams and Firehose?** Data Streams gives you control over reading, retention and replay. Firehose is a managed delivery to a storage or analytics destination, with no consumer to write. If you only want to drop the stream somewhere, Firehose is enough. **Can these services be combined?** Yes, and that is the most frequent case. A common pattern is an event routed by EventBridge to several SQS queues, each consumed by a separate process, with a dead-letter queue for failed messages. --- # What is multi-tenant and how do you implement it on AWS? - URL: https://www.premaccess.com/en/quest-ce-que-le-multi-tenant-aws-cloud-application-architecture (French original: https://www.premaccess.com/quest-ce-que-le-multi-tenant-aws-cloud-application-architecture) - Published: 2020-03-25 · Category: Amazon web services Multi-tenant on AWS: what a shared architecture changes for a SaaS vendor, and how to implement it with DynamoDB, Cognito and IAM policies. ![](/assets/media/529f9f_9dfe65b4dc43433eb241ce65ee351ea3.webp) SaaS application vendors know it well: fixed infrastructures, known as single-tenant, are easy to deploy but have their limits, particularly in terms of maintenance. That is why we strongly advise you to move to multi-tenant. Many of you hesitate to take the step. Your fear: that your [clients](/business-case)’ data will not be secure. Yet, on AWS, this is possible thanks to the combination of three microservices: **Cognito, IAM and DynamoDB.** Having explained what a multi-tenant architecture is, we show you how to use these three services on AWS to implement it. ### Table of contents - What is a multi-tenant infrastructure? - How do you do multi-tenant with AWS? - Organise your databases with DynamoDB - Create your users - Define security rules ## **What is a multi-tenant infrastructure?** Before going any further, let us explain the term “Tenant”: it means “lessee”, “customer”. Each customer bringing together a “group of users”. ### **Single-tenant model** In a single-tenant architecture, one single application is used by several clients, but each one has its own version of the application installed in a dedicated instance. This model has several advantages: - A clear separation between each client, and therefore between each version of the application. - Client A’s data is not mixed with client B’s. - Each client has its own database and its own application server. ![](/assets/media/529f9f_ff13a9fbb9ec4fb3b0caa59cfda961c0.webp) But it can very quickly become complicated to administer. Indeed: - The more clients there are, the harder it is to manage the different versions of the application on each infrastructure. - The fixed cost of each infrastructure can be penalising for low-traffic clients. - From 100 clients onwards, it is imperative to automate infrastructure management, notably with solutions such as [BAM](/bam)*. - From 1,000 clients onwards, it is practically no longer manageable. ### **Multi-tenant model** By contrast, in a multi-tenant architecture, a single application instance serves several clients. Resources (and databases in particular) are shared there. ![](/assets/media/529f9f_c14418ed8d514807bce8658f72643e54.webp) With a single global infrastructure, instead of one per client: - It is easier to maintain: when a change is made to a file, every client benefits from it. Updates are simpler to carry out. - You reduce your usage costs on the Cloud. - Response times are much faster. - Client management is simplified, whether there are 10 of them or 10,000. In return, since clients’ data is mixed together, the software has to be developed to separate client data logically. We will see later that the technologies built into AWS make this difficulty easy to resolve. ### **Hybrid model** There is also a hybrid approach that makes it possible to optimise your infrastructure without having to make many changes to your application. ![](/assets/media/529f9f_f0da9838778d44c6a37f9eb58a3597e0.webp) In a hybrid approach, only the application is shared. In this case, each client has a dedicated database within the same instance, as well as a login and a password. This solution has the advantage of being easy to implement while starting to make economies of scale on infrastructure costs. ## **How do you do multi-tenant with AWS?** When building a multi-tenant architecture, the crucial issue is, of course, to secure the data so that it is not accessible to everyone. SaaS application developers must be able to identify a user, to link a piece of data to its tenant, but also a user to its tenant, and to know which rights have been granted to which user. For that, on the AWS Cloud, we advise you to combine the DynamoDB, Cognito and IAM services. ## **Organise your databases with DynamoDB** In DynamoDB, every table in your database must have a column for storing a reference to the Tenant. As a general rule, this is a client identifier (organizationId). ![](/assets/media/529f9f_42b29d815f2242a7939e887ac02c7938.webp) ## **Create your users** Alongside this table management, Amazon Cognito lets you add users to your SaaS applications. In a multi-tenant infrastructure, this service will list the different clients (and therefore their users and their groups) along with their identifiers. It will also associate custom attributes with each user according to the tenant they are tied to, in order to secure their authentication and manage their permissions. What is more, AWS handles all the security and the sign-in for you. All the latest standards, notably multi-factor authentication, are available without any development on your part. Each user is a member of a group. You can therefore manage access to data in a fine-grained way according to group. ## **Define security rules** Finally, with IAM (Identity and Access Management), you will define the security rules (policies) associated with each group. Thanks to these rules, filters (LeadingKey) will be created in the DynamoDB database. The user will therefore access only the data linked to the filter. They will be unable to see the rest, as if they were in a dedicated enclave. ![](/assets/media/529f9f_675bd3f6db1d49f28124eb3496758a9f.webp) ## **Conclusion** Between single-tenant and multi-tenant, we advise you to choose the second infrastructure model, because it offers considerable benefits: easier maintenance, lower costs, simplified client management… What is more, thanks to the combination of the three AWS services (DynamoDB, Cognito and IAM), data security is guaranteed there. And managing access rights to client data does not have to be done by the developer in their code. It is managed separately with AWS. This has several advantages: - Multi-tenant management is independent of the rest of the code. - More generally, managing access control to the data is thus independent of the SaaS application code. - It is possible to use other services to produce statistics on data by client, notably with QuickSight. * BAM (Build Automation Machine) is an innovative solution created by [***Premaccess***](/). It automates the management and the lifecycle of your infrastructures and their deployment on AWS. [Do not hesitate to contact us with any questions or projects!](/#contact) **What is the difference between single-tenant and multi-tenant?** With single-tenant, each client has its own infrastructure instance. With multi-tenant, clients share the same infrastructure and are isolated logically by the data and the access rights. Multi-tenant reduces the cost per client, at the price of a stronger isolation requirement. **Is multi-tenant less secure?** It moves security from the physical boundary to the logical layer. Isolation then rests on the design of the partition keys and on access policies that restrict every query to its tenant. Correctly designed, this isolation is verifiable; badly designed, it is invisible until the incident. **How do you isolate each client's data on DynamoDB?** By bringing the tenant identifier into the partition key, then restricting access through policies that make reads conditional on that key. Isolation is thus carried by access control, not only by the application code. **When should you stay single-tenant?** When a regulatory or contractual constraint imposes physical separation, when a client demands its own region or its own encryption, or when the number of clients is small and the unit value high. A hybrid model, shared by default and dedicated on demand, is common. --- # Client cases ## Fitizzy — Retail · Ready-to-wear - URL: https://www.premaccess.com/en/business-case/fitizzy (French original: https://www.premaccess.com/business-case/fitizzy) Improving the user experience and getting more value from Big Data management - Architecture: Serverless - SaaS isolation: Multi-tenant - Value creation: Big Data **The need** Fitizzy is an omnichannel shopping assistant that helps online shoppers choose the right clothing size, thanks to an intelligent algorithm embedded in e-commerce sites.Adopted by major retailers such as Promod, Morgan, NafNaf and Devred, the solution has seen a sharp rise in traffic on its widgets. Fitizzy needed an IT partner able to modernise its infrastructure while improving the user experience and the management of its Big Data volumes. **Our approach** To find out more about this project, read our article *"*How Fitizzy, a size recommendation solution, is investing in AWS to better shake up the ready-to-wear market*".* [Read the case study](/comment-fitizzy-investit-aws-marche-pret-a-porter) ## Prestigia — Luxury travel - URL: https://www.premaccess.com/en/business-case/prestigia (French original: https://www.premaccess.com/business-case/prestigia) Delivering a smooth experience and an instant response time - Revenue growth: ×50 - Partnership: 20 years - Unique visitors/month: 500K+ **The need** Prestigia is a high-end travel booking site specialising in luxury hotels and homes. To guarantee a smooth, fast customer experience for its users, the platform must ensure instant response times despite high traffic. **Our approach** To find out more about this project, read our article *"*Refactoring, migration, finOps: how Prestigia, a leader in luxury hospitality, innovates with AWS*".* [Read the case study](/comment-prestigia-leader-hotellerie-luxe-innove-avec-aws) > Premaccess has been our sole partner for over 20 years. Their availability and operational efficiency helped us multiply our revenue by 50. — Youness Chraibi, CEO, Prestigia (translated from French) ## My Tour Live — Media · 360° Video - URL: https://www.premaccess.com/en/business-case/my-tour-live-videos-a-demande (French original: https://www.premaccess.com/business-case/my-tour-live-videos-a-demande) Migration from Google Cloud to AWS - Migration: GCP→AWS - Distribution (incl. China): Worldwide **The need** Launched in 2019, My Tour Live offers remote guided tours in 360° video, with a strong interactive dimension. Initially hosted on Google Cloud, the platform quickly ran into two major limitations: 1. Limited availability of Google Cloud in certain strategic areas, notably China. 2. Lack of technical flexibility: AWS offers a broader range of microservices, essential to support gradual growth. **Our approach** To find out more about this project, read our article *"How My Tour Live is developing an on-demand 360° video service on AWS".* [Read the case study](/my-tour-live-developpe-saas-video-360-aws) > The human expertise and the closeness of their team allowed us to migrate to AWS with complete peace of mind. — Franck Aldraï, Founder, My Tour Live (translated from French) ## FBD Bmodel — Textile industry - URL: https://www.premaccess.com/en/business-case/fdb-bmodel-industrie-du-textile (French original: https://www.premaccess.com/business-case/fdb-bmodel-industrie-du-textile) Using data to support the textile economy in Europe **The need** The European clothing industry, long weakened by offshoring to Asia, is now tending to move production back home. "Made in France" and "Made in Europe" are enjoying renewed interest. To stay competitive, European SMEs are betting on high value-added production. But given their modest size (90% have fewer than 50 employees), they struggle to build solid sector connections and to access consumer analysis tools. The European Union supports them through FBD BModel, a data portal for retail players (consumers, brands, manufacturers, researchers), to produce better, faster and more efficiently. **Our approach** To find out more about this project, read our article *"What if we used data to boost the textile industry in Europe".* [Read the case study](/data-pour-dynamiser-industrie-du-textile-en-europe) ## PMU — Horse-race betting - URL: https://www.premaccess.com/en/business-case/pmu-paris-hippiques (French original: https://www.premaccess.com/business-case/pmu-paris-hippiques) Creating event mini-sites with serverless. **The need** Pari mutuel urbain (PMU) is a French horse-race betting company whose activities are the design, promotion, marketing and processing of bets on horse races. Since the law opening up the gambling market in May 2010, the company also offers sports betting and online poker games. **Our approach** - Management of 3 serverless projects on AWS: creation of event mini-sites - Being able to deploy these three sites easily and quickly on AWS. ## Vranken Pommery — Spirits - URL: https://www.premaccess.com/en/business-case/vranken-pommery-spiritueux (French original: https://www.premaccess.com/business-case/vranken-pommery-spiritueux) Optimised multi-site management **The need** Vranken-Pommery is the second-largest Champagne wine group. Its portfolio includes the champagne brands Vranken and its Diamant and Demoiselle cuvées, Pommery and its Louise and POP cuvées, Charles Lafitte, Heidsieck & Cie Monopole. **Our approach** - Ensure that all the brand sites have a technical base and one reversible site per brand via the same framework, in a scalable way. ## Compagnie Des Alpes — Tourism · Leisure - URL: https://www.premaccess.com/en/business-case/compagnie-des-alpes-tourisme (French original: https://www.premaccess.com/business-case/compagnie-des-alpes-tourisme) Governance and advice for migration to the Cloud - Ski operator: #1 - Ski & leisure sites: 10+13 - Cloud strategy: 3-5 years **The need** La Compagnie des Alpes (CDA) is a French company, a subsidiary of the Caisse des Dépôts, created in 1989. Initially focused on operating ski areas – of which it is the world’s leading operator – it broadened its activity to theme parks from 2002. Today, the group is the 4th largest European operator of leisure parks. CDA operates 10 major ski areas in France (Tignes-Val d’Isère, La Plagne, Méribel…) as well as 13 landmark leisure sites (Parc Astérix, Futuroscope, Musée Grévin, etc.). It is also active in accommodation and the online distribution of mountain holidays (notably through Travelfactory, acquired in 2018). **Our approach** - Structure Cloud governance over 3 to 5 years - Prepare a migration of on-premise infrastructure to the Cloud - Carry out group-wide strategic thinking on Cloud investment ## Lamie Mutuelle — Health - URL: https://www.premaccess.com/en/business-case/lamie-mutuelle-sante (French original: https://www.premaccess.com/business-case/lamie-mutuelle-sante) Setting up a data lake​ **The need** Lamie Mutuelle came into being in 2015 from the merger between the health insurer Intériale Filia and Mutuelle Familiale France et Outre-mer. Intériale Filia was in charge of collecting the contributions of police civil servants and of other territorial bodies such as the Ministry of the Interior and the Conseils Généraux, for serving staff and retirees. Mutuelle Familiale, for its part, mainly provides health cover for expatriate or seconded staff, essentially in the overseas territories and abroad. These two organisations merged to form the inter-professional division of the Intériale group. Lamie Mutuelle’s main areas of activity are insurance, health and personal protection. **Our approach** - Setting up a data lake for health data - Retrieving this data securely (internally and through partners) ## GEB — Industry - URL: https://www.premaccess.com/en/business-case/geb-industrie (French original: https://www.premaccess.com/business-case/geb-industrie) Hosting, managed services and AWS Cloud consulting​ - Monitoring: 24/7 - Bespoke product: Extranet **The need** Since 1986, GEB, a specialist in formulation chemistry, has developed a pioneering range of plumbing sealing solutions, driven by the spread of running water in France. Its core business: consumables for the installation, repair and renovation of seals in sanitary plumbing and heating. This family business has many subsidiaries around the world. Its objective: to remain the leader in its market. **Our approach** - Hosting and managed services (website, email) ## Pumpkin — Fintech · Payments - URL: https://www.premaccess.com/en/business-case/pumpkin-paiement-en-ligne (French original: https://www.premaccess.com/business-case/pumpkin-paiement-en-ligne) Building a queuing system with filtering​ - Users: 1,2M - Volume processed: €250M+ **The need** Launched in 2014 in Lille, Pumpkin started out as a mobile app for instant, free payments and reimbursements between individuals in a secure environment. The app lets users send or request money from their contacts through the interface of a mobile number. With 1.2 million users and more than 250 million euros exchanged, Pumpkin now offers a current account and a bank card together with a cashback programme, and makes it possible to manage savings or transfer payments. Pumpkin aims to increase the share of purchases made through its payment solution from 20 to 30% a year. **Our approach** - Optimise the management of their student-union ticket sales: when student unions integrate their online payment system, heavy traffic is generated on the platform. That peak can bring the infrastructure “down”. To solve this problem, a queuing system with filtering was put in place. - Receive advice on AWS regarding Cloud architecture and scalability (via AWS ECS). ## Question Direct — Real time - URL: https://www.premaccess.com/en/business-case/question-direct-interactions-en-temps-reel (French original: https://www.premaccess.com/business-case/question-direct-interactions-en-temps-reel) Maintenance and migration to a microservices architecture **The need** [Question.direct](http://Question.direct) is an online interactive platform for running real-time exchanges between a speaker and an audience at a range of events: conferences, meetings, classes, debates, seminars, etc. It is intended for speakers, facilitators and organisers who want to: - Moderate questions from the audience (collection, grouping, prioritisation, display, archiving) - Poll the audience live via multiple-choice questions, votes, word clouds, ratings… **The platform approached Premaccess to:** - Outsource maintenance of the application - Develop new features - Evolve the architecture: move from a monolithic system to more flexible, scalable microservices **Our approach** - Guarantee the stability of the application with regular maintenance - Launch new features quickly to meet user needs - Adopt a microservices architecture to make deployments and technical changes easier ## Behind The Bet — Sports data - URL: https://www.premaccess.com/en/business-case/behind-the-bet-donnees-sportives (French original: https://www.premaccess.com/business-case/behind-the-bet-donnees-sportives) Optimising technical performance​ **The need** Behind the Bet is an expert in the analysis and interpretation of sports data. Its ambition: to revolutionise the sports betting sector by drawing on the power of Big Data and Artificial Intelligence to improve the experience of bettors. Thanks to its advanced algorithms and a rich, accurate database, the platform makes it possible to identify high-potential betting opportunities quickly. **Our approach** - Audit the existing environment - Optimise the technical stack and reduce infrastructure costs - Support the evolution of the platform towards a higher-performing and more scalable architecture ## Ariane Lab — Data intelligence - URL: https://www.premaccess.com/en/business-case/ariane-lab-data-intelligence (French original: https://www.premaccess.com/business-case/ariane-lab-data-intelligence) Moving from on-premise hosting to the AWS Cloud **The need** Ariane Lab specialises in push channels and recommendation. Its solution allows companies to recommend their products and services to a highly qualified audience, and to do so in real time. The recommendation is sent to targets in push form through affiliate sites.Created in partnership with the research centres of Polytechnique and the CNRS. **Our approach** **Moving from on-premise hosting to the AWS Cloud in order to:** - Increase the volume of web push sends - Improve load-handling capacity - Resolve scalability problems - Consolidate statistics per user (ID): unify a volume of distributed data (events, sends, clicks…) for unified reporting, and make the data available in Amazon QuickSight according to business needs ## La Maison De Mirèio — Marketplace - URL: https://www.premaccess.com/en/business-case/la-maison-de-mireio-marketplace (French original: https://www.premaccess.com/business-case/la-maison-de-mireio-marketplace) Building a scalable, evolving marketplace **The need** La Maison de Mirèio is a marketplace specialising in products from Provence. It allows local producers to join forces to promote their craft to customers with a taste for the region’s way of life. Founded and run by the producers themselves, La Maison de Mirèio aims to become the showcase of the Provençal selection.The founders launched this e-commerce site to sell together, while wanting a turnkey solution (not running on their own infrastructure): they therefore called on Premaccess to take this step, in complete safety and with a very demanding time-to-market. **Our approach** - Launch a working marketplace quickly, on a controlled budget - Enable producers with no technical skills to sell online easily - Design an infrastructure able to adapt to growth in traffic and sales ## Zodiac Aerospace — Aerospace · Safran - URL: https://www.premaccess.com/en/business-case/zodiac-aerospace-aeronautique (French original: https://www.premaccess.com/business-case/zodiac-aerospace-aeronautique) Cloud migration and change management **The need** Zodiac Aerospace is a long-established French aerospace company, founded in 1896 and integrated into the Safran group in 2018.A supplier of systems and equipment for aircraft, the company wanted to modernise its infrastructure to remain a leader in a highly technological sector. Migrating to the Cloud had become a strategic necessity in order to benefit from the best technologies available. **Our approach** - Initiate a Cloud transition aligned with business priorities - Familiarise decision-makers with the benefits and constraints of the Cloud - Trigger internal momentum conducive to the transformation - Propose a structured migration plan based on relevant AWS services ## BNC SA — Banking - URL: https://www.premaccess.com/en/business-case/bnc-sa-banque (French original: https://www.premaccess.com/business-case/bnc-sa-banque) A complete overhaul of the Cloud architecture **The need** Specialising in money transfer and currency exchange in the French overseas territories and in France, BNC had already been relying on AWS for several months before meeting the Premaccess team. After various unsuccessful engagements with other providers, the company was looking for a new Cloud hosting model, one that would break with its technological constraints. **Our approach** - A complete overhaul of the architecture in order to: 1. Meet AWS best practices and services through a modernised technical framework 2. Ensure financial and performance optimisation 3. Verify compliance with the security rules of the banking sector ## Sourcin — BioTech · E-Learning - URL: https://www.premaccess.com/en/business-case/sourcin (French original: https://www.premaccess.com/business-case/sourcin) Building an e-learning platform for biotech **The need** Passing on complex technical procedures in biotechnology is a critical challenge. Incorrect handling can have serious consequences. To meet this need, Sourcin has designed a collaborative multimedia platform dedicated to e-learning. This platform brings together all of its clients' internal procedures in the form of short videos called Mediabooks. Main objective: to train production operators continuously, and support them directly at their workstation. With the support of the Premaccess teams, the platform migrated to the AWS Cloud to gain in security, availability and scalability. **Our approach** - Offer biotech companies a flexible e-learning solution, accessible at any time - Optimise training materials by drawing on companies' real domain knowledge - Spread know-how at scale, to ensure continuous learning - Secure and back up all training content - Guarantee worldwide access to the training, 24/7 - Structure Sourcin's IT infrastructure to support the rapid growth of the model ## Afilio — Services - URL: https://www.premaccess.com/en/business-case/afilio (French original: https://www.premaccess.com/business-case/afilio) Coping with omnichannel connection peaks **The need** The Afilio group manages a network of more than 50,000 publishers and works with more than 400 major advertisers (including Nike, TAM…).It handles more than 1.5 billion clicks per minute on average, and up to more than 3 billion orders per day during peak trading periods (Black Friday, sales, etc.). To maximise click-through rates on omnichannel campaigns and guarantee the stability of the platform, Afilio, the world’s third-largest affiliate marketing player, decided to adopt new IT methods. **Our approach** - Optimise platform performance to handle the extreme volumes generated by e-commerce campaigns - Position itself as the leader in omnichannel affiliate marketing, particularly on mobile - Sustain the effectiveness and monetisation of its affiliate programmes internationally - Guarantee continuous availability of the platform, whatever the region of the world ## Arthus Bertrand — Luxury (founded 1803) - URL: https://www.premaccess.com/en/business-case/arthus-bertrand (French original: https://www.premaccess.com/business-case/arthus-bertrand) Harmonising the IT methodology of each of its brands​ **The need** A French house founded in 1803, Arthus Bertrand is known for its craftsmanship in fine jewellery, medals and exceptional objects. Present in around forty countries, it makes more than 30% of its turnover from exports. Aware of the lack of shared structure between its various digital entities, management wanted to harmonise the IT methodology across all of its brands. **Our approach** - Support the group’s digital modernisation in a luxury sector undergoing profound change - Optimise the company’s overall IT performance - Improve the flow of information between the entities - Harmonise the management of the e-commerce sites, in particular through the Magento CMS - Host new digital projects on a centralised infrastructure ## Travel Factory — Tourism - URL: https://www.premaccess.com/en/business-case/travelfactory (French original: https://www.premaccess.com/business-case/travelfactory) Developing innovative offers and accelerating their time to market **The need** The Travel Factory group wanted to accelerate its digitalisation while rationalising its investments and optimising the performance of its information system. In a highly digitalised tourism sector, the challenge is to stay competitive by offering a smooth user experience and differentiating offers. **Our approach** - Modernise the information system infrastructure without disrupting the business - Improve coordination between the marketing, finance and IT teams - Create an environment conducive to rapid innovation and to bringing new offers to market - Build a collaborative technical hub and strengthen the links between the teams ## SFR — Banking - URL: https://www.premaccess.com/en/business-case/sfr-payment-services (French original: https://www.premaccess.com/business-case/sfr-payment-services) Go-live of a virtualised banking platform in record time​ **The need** SFR Payment Services, a payment institution licensed by the ACPR, wanted to deploy its first virtualised banking platform through its branch network in the French overseas territories, within a very short timeframe. Faced with a banking sector in the midst of digital transformation, the aim was to ensure agility, performance and compliance all at once, while keeping control of the quality / implementation time / cost ratio. **Our approach** - Achieve the rapid go-live of a virtualised banking platform - Gain technical agility while guaranteeing the security and reliability expected in the financial sector - Make the most of internal banking Big Data - Integrate new digital practices: blockchain, HRIS, chatbots, multichannel…