LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Security
  • Minimize downtime
  • Allow for Developers to move fast
  • Be prepared for running a subset of critical services on-premise
  • Minimize operational overhead
  • Minimize expenses

Was this helpful?

  1. Development
  2. Devops

Operations Base Principles

PreviousObservabilityNextSecurity

Last updated 1 year ago

Was this helpful?

Here are the principles that we apply when deciding how to run Operational workloads. They come from the management team at Stafrænt Ísland.

  1. Secure access to data and services

  2. Minimize downtime

  3. Allow for Developers to move fast

  4. Be prepared for running a subset of critical services on-premise

  5. Minimize operational overhead

  6. Minimize expenses

Security

We utilize all our expertise when provisioning infrastructure to apply state-of-the-art security in the cloud. We do our part to fulfill our responsibility in the .

Minimize downtime

We strive to apply changes to our Production environment that we are certain of the impact. That requires us to have pre-Production environment that is very close to the Production one where we exercise all changes before they are applied to Production. We also monitor our Production environment according to the Service-Level Agreements(SLA) for the individual services running there.

Allow for Developers to move fast

We need to allow the Organization be able to deliver new services to the users and iterate on those quickly and safely. The same goes for fixes and improvements. That's why our Org has invested heavily in infrastructure as well as engineering practices and processes that allow the teams to create new applications with minimal operational overhead. This is achieved by standardizing and pre-packaging all infrastructure concerns in libraries and automation while keeping up with security standards.

Be prepared for running a subset of critical services on-premise

As part of Iceland's government infrastructure, we need to be prepared to run a subset of our services in a local data center. To achieve that, we need to use technologies that are known to work on-premises. Fortunately, the majority of the core tech today is open-source or is based on open standards, which makes this requirement quite achievable. Non-critical services can utilize all the advantages of the cloud.

Minimize operational overhead

We are using fully managed services in the cloud as much as possible since the TCO is much lower then managing them ourselves. We try to focus our operational effort on the unique services our Organization develops.

Minimize expenses

We utilize our cloud expertise to minimize the cost of running in the cloud.

Shared Responsibility Model