The Architecture Principles are guidelines for the construction of the architecture.
På denne siden:
The following architecture principles has been defined for the solutions. The principles are document as suggested by TOGAF.
The architecture principles below is described like TOGAF recommends.
Free and open-source software
The components and solutions are Free and Open Source.
Possibility to share the platform as Open Source. The possibility to create an Open Source community around the platform.
- Code developed is shared on GitHub. See License.
- We have our backlog on Github.
- Can’t use closed source products in the platform
- Can’t use products with licensing limiting use and modifications
- Others can reuse and modify our components and solutions
Use Web Standards.
Can use standard tools and developers does not need to have special skills to develop components in the platform or applications to run on the platform.
- Formats and frameworks used need to follow standards
- We use JWT in authentication cookies
Build with modern and popular frameworks
When needing to choose between different framework with similar capabilites select the most modern and popular framework.
The project is open source and it is a big advantage to build the solution on frameworks that developers love to use. This gives better access to resources with the needed competency.
- We build the frontend using React. The most loved web framework
- We use .Net core that developers love the most
- We use Linux Docker containers in Kubernetes. The 3 most loved platforms
- We use Visual Studio Code and Visual Studio. The two most loved development environments
Favor standards over custom
Whenever we need to store information we favor standard formats for that information over creating a custom format.
Standard formats are documented and is some cases it exists 3. party tools to edit information.
- We use BPMN 2.0 to define the process for applications
- We use XACML 3.0 to define authorization policies for applications
- We use JSON as general format.
Principle We should try isolate application and data own by one organization from others.
Reduce risk for one organization affecting service for another organization.
- Seperate Kubernetes Clusters for each organization
- Seperate data store for each organization
Design and build for Public Cloud
The solutions should be deployed to a public cloud solution. The architecture need to support that.
Using public cloud infrastructure from one of the big vendors gives cost savings, the team can be more agile and the solutions can take scale.
- Additional security measures
- Need to build knowledge about cloud solutions
Limit cloud lock-in
The architecture should try to avoid technology that locks the platform to a specific public cloud vendor. But not for all costs. In many cases it would still make sense to choose a managed service only available in a given public cloud.
The goal with this principle is that it should be possible to move the solution to a different cloud provider without needing to build everything from scratch.
- Docker and Kubernetes is used for containers and orhecstration of containers.
- We use document databases and BLOBS for storing data.
- Everything talks through APIs.
Build as microservices
The platform is built as microservices. Related functionality is grouped in to seperate applications and deployed as containers. Apps created in Altinn Studio will be deployed as microservices/apps.
The different components can be scaled differently, it can be deployed independently. Reduced deploy time. Different teams can be responsible for different microservices/apps.
- Functionality in Altinn Platform is seperated in Authentication, Authorization, Profile, Storage, Pdf and Register components
- Applications created in Altinn Studio is deployed as microapps to Altinn Apps
Design for automation
The component should be created in a way that they support automation in development, deployment and operations.
Reduce the required effort to develop and operate the platform.
- We use Continuous integration
- We use Continuous deployment
- We build Infrastructure as code
- We use Automatic scaling
- We monitor and do automatic recovery of components
Favor managed services
We should use manages cloud services when possible.
Reduce effort needed to host and scale the platform.
- Use managed PostgreSQL in Azure for Gitea
- Use managed CosmosDB as document database
- Use Azure blob storage for storing data
- Use Azure Kubernets Services to manage the Kubernetes Clusters
- Use Azure Api Management as API-management platform
Security in depth
All components should authenticate and authorize requests.
We can’t trust other components.
- Components in Altinn Platform authenticates and authorize end user even if the request comes throug a application that also require the same
- We use API management to control traffic between Altinn Apps and Altinn Platform.
Developers should be able to create applications on any platform, and our platform should never be locked to a single operating system or processor-architecture.
- We use .NET Core or Java to build components.
Applications should be deployed as containers.
The rationale to use containers is that we get a consistent runtime environment that can run anywhere. Isolate runtime environment. Consistency.
- Deploy and run applications/components in docker containers.