Image source: https://flic.kr/p/pi5a1Y, Creative Commons License
Public speaking, technology and cloud consulting, training, software architecture workshops, etc. are an important part of my business beside working on our products, foremost time cockpit. When doing such projects, I see many software development teams struggle with platform selection. Should we build a web app or a native app? Is .NET the right platform for developing our backend or should we move to Node.js? Should we bet on Windows or aim for a cross-platform solution that supports Linux, too? Is it future-proof to build on top of UI framework X? Should we integrate/buy a standard product for dashboards or build our own component? Dicisions for questions like these can have massive consequences. They can make difference between long-term success and failure of projects. In this blog article I like to share our current thinking in this regards concerning our own products.
Assess Stability of Technologies
Whenever we make decisions about using this or that technology/architecture, we try to anticpate its stability and availability over time.
Here are some influence factors that we consider in this context:
- Relevance for our users (e.g. ratio of users with Windows as their primary operating system when using our front end)
- Relevance of the underlying industry standards (e.g. REST with Swagger vs. OData vs. GraphQL, # of market-leading products using/supporting the standard)
- Level of activity (e.g. GitHub checkins, release frequency, new features vs. just support releases, # of blog posts/articles/books about a technology)
- Trust in supplier (e.g. size of community, tooling ecosystem, commitment of supplier, financial situation of supplier, history of supplier)
- Long-term support (e.g. published road-maps, availability of long-term support contracts, published retirement plans)
- Stability of the market (e.g. typical lifetime of techologies in the correspondig area in the past)
Assessing factors like this is not easy. The IT market is very dynamic and it is chaning at an impressive speed. I spend a lot of time looking at new tools, frameworks, platforms, open source projects, languagues, frameworks etc. and yet I can only oversee a small fraction of the overall market. We consciously exclude some parts of the software market because otherwise the task would be overwhelming (e.g. we do not even look at the Java ecosystem in our company).
Decouple (Only) Where Necessary
For time cockpit, we try to decouple our software from underlying technologies whenever we don't think the foundation is not stable.
Tools that we use for decoupling are for example:
- The classic: Dependency Injection
- Domain-specific languages (DSL)
The user interface is a good example for that. We describe large parts of our UI in an XML-based DSL. XML is quite stable. We think it will be around for a very long time. In the past, we generated various flavors of XAML from it (for WPF and Silverlight). Today, we generate HTML5/JavaScript/CSS from it. With our DSL, we don't lose our investment when switching the UI technology.
- Decouple components with RESTful Microservices
We consider web-related protocols like HTTP, OpenID Connect, JSON, etc. as stable. They help us isolating system components so that we can change their implementation without affecting connected components too much.
- Use widely accepted standards like SQL or OData
Using such standards enable us and our customer to use COTS tools like report generators, dashboard tools like Power BI, etc. We can focus on our core added value and let others think about technological questions in their domain.
However, decoupling comes with a cost in many cases. It often means that we have to develop more plumbing code, we have to solve performance issues originating from additional abstraction layers, etc. Therefore, we think it is important to think about where decoupling is necessary.
Our Current View of the World
So what is our current thinking for our own projects?
User Interface
In our company, we have defined two important premises from the very beginning. They are been valid today:
Premise #1: We definitely need a browser-based UI, other front-end platforms (e.g. native mobile apps) are nice-to-have.
Premise #2: We cannot/don't want to afford to build multiple separate UI solutions for different platforms.
These statements have had important consequences on our entire technology strategy. Our original strategy we defined eight years ago (use Silverlight in the browser, WPF on the client and let them share large parts of the code) worked but turned out not to be sustainable on the long run. Luckily, we decoupled large parts of our UI using the XML-based DSL I mentioned before. So we could do a switch.
Today, we consider web technologies for UI development as the best way for our products. Here is what we have chosen:
Our existing HTML5 client for time cockpit has been built on this stack. It currently uses Angular 1.5. We try to follow Angular's style guide to write new code in an Angular 2-friendly way. Gradually, we will move to Angular >= 2 once the ecosystem (primarily Kendo UI) around the new major Angular version will have been stablized.
Desktop App Strategy
We have not finally decided our desktop app strategy yet (no hurry there, our WPF client works fine and the decoupling strategies mentioned above enable us to add value to both WPF and HTML5 without having to duplicate all our code). Two options are currently under discussion:
- Build our browser-based app in a progressive style (progressive web app)
- Use an Electron-based approach
We have a tendency towards the second approach.
We have ideas for native apps, too. However, this components are nice-to-have. Currently, we are playing with NativeScript. It would allow us to reuse our knowledge in web technologies to a large extent.
Communication Protocols
We love RESTful Web APIs. They decouple technological decisions for client and server.
Granted, that is a quite generic statement and most people would agree to it nowadays. Here are some more details:
- We use plain RESTful web APIs with Swagger metadata for specific business transactions or complex operations.
- We use OData on top of REST to enable client-driven data retrieval and manipulation. This enables the use of OData-enabled client tools like Excel and Power BI.
- We use OpenID Connect for authorization and delegation.
- We consider using Websockets for more bidirectional communication mid to long term.
- We consider not only consuming Webhooks but also offering outgoing webhooks for easier integration of our SaaS solutions in customer environments.
Backend Strategy
We love C# and .NET on the server. We complement it in smaller side projects with Node.js.
Our codebase on the server is and will be written in C# based on the .NET framework. Today, we use .NET 4.x (more specifically: ASP.NET Web API on top of OWIN/Katana). However, we will gradually migrate to ASP.NET Core once the ecosystem stabilizes (today, many NuGet packages we need are not production-ready for .NET Core).
Cloud Strategy
We are and will be betting on Microsoft Azure's Platform-as-a-Service (PaaS) offerings to make full use of the cloud's potential.
We complement our PaaS-strategy with rising use of Docker containers. Today, Docker is primarily used in our internal development tool chain. Over time, we expect that Docker containers will be a vital part of our production systems running SaaS solutions like time cockpit or EMIRate. Today, Azure does not offer a PaaS solution for Docker that suites our needs. We are closely monitoring the development of Azure in that area.
Here are some details:
- Azure App Service is the core for all web apps and web APIs.
- Azure SQL Database is our primary data store. It is complemented by Azure Storage (tables, blobs).
- In the past, we used time cockpit's built-in scripting support (Python) to automate customer-specific tasks. Although this will continue in the future, we use more and more Azure Functions with C# Scripting and Node.js for that. They use our RESTful web APIs in the background.
- Today, we use Identity Server as our component for OpenID Connect. In the mid-term future, we expect to switch to Azure Active Directory (more specifically a combination of AAD and AAD B2C) instead. Today, AAD B2C lacks some features that we absolutely need. We are closely monitoring the development in AAD.
- We switched from local CI/CD tools to cloud (in particular Visual Studio Team Services) for all components that are under active development.
- We have been increasingly using Application Insights vor application monitoring and we plan to further extend it.
What We Will Not Do
- Although it is nice to know that more and more of our base technologies are available on multiple platforms, we have to plans to switch to Linux on our servers or Mac OS on our developer workstations.
- Although Docker will make us more independent from Azure, we are not planning to move away from it.
- Although Node.js is quite useful for server-side programming with TypeScript and for console-based tools, we do not plan to replace .NET/C# on a larger scale.
- We do not plan to build platform-specific, native mobile apps.
- We do not plan to use C# on the client (e.g. with Xamarin) in the near or mid-term future.
Questions?
If you have questions about our technology selection or you need consulting for your specific project, feel free to contact me at rainer@software-architects.at. I am looking forward to hearing from you.
comments powered by