Wednesday, September 25, 2024

Update on my latest activities

In this article, we'll consider some of the software development environments that I've worked with  lately. This is a precursor to the subsequent posts on the impact that microservices and containers have had on  software development.

The .Net tech stack

Over the past 13 years I’ve used the typical .Net tools extensively, both as a developer and an architect. For example, this includes C#, SQL Server, SQL Server Reporting Services, Visual Studio, TypeScript and Angular.

Most of my projects have been built on the .Net platform, such that C# has been the primary programming tool for business logic. Similarly, SQL Server was the principal RDBMS for these projects, although I’ve often sued other tools interchangeably (e.g Oracle).

Visual Studio has been the editor of choice, giving us access to tools, such as Team Foundation Server, which was replaced by Azure Dev Ops.  Thus, we could use the built-in tools to track projects using an Agile approach, within the TFS/Azure Dev Ops framework.

For user interfaces, I’ve used various versions of Java Script, such as TypeScript. However, my preference is Angular, because it lends itself well to object-oriented design and development, very much like C#.  

In all the cases referred to above, as an architected I’ve been able to share my hands o experience with developers, allowing them to understand nuances that I came across as a programmer. I still enjoy being hands on to help my team solve problems and navigate proofs of concepts for approaches that they are not familiar with.

Serverless applications using microservices

I’ve been using microservices for virtually all of my applications since around 2019. Ther most extensive use has been for Simulation Magic, as described on the web site at www.SimulationMagic.com .  In the various projects for which I’ve been the architect, we’ve used primarily Kubernetes to manage the containers and Docker to create the containers themselves.

However, variations on this theme include various tools from AWS, which essentially mimic the Kubernetes/Docker paradigm (see below).

From my perspective as an architect, the primary advantage of this approach is to spin up/destroy containers as needed and automate the connectivity between them. I also like how microservices can be sued to create virtual servers for testing proofs of concepts, load management, etc.  

Finally, I like the way that responsibilities are compartmentalized within containers. To me, this is simply the next step in the OO paradigm, which aims to ensure that processes are black boxes that communicate via input/output parameters. This allows us to easily replace components within any system that I’m working on, either to repair or improve them.

AWS as microservices

I worked with AWS last summer for IBM on a project for Immigration Canada. This involved creating the infrastructure for a new digital application process for Canadian passports. The AWS system was the foundation for this project, which required various types of connectivity between platforms for security, verification of identity using AI, saving applications, training an image recognition, system, etc.

We encountered some latency issues with AWS, with respect to loading of services that were called automatically. However, we worked directly with Amazon engineers to address these problems. As a senior solutions architect, I was responsible for ensuring that dev team members were able to continue working without being blocked by such issues.

NoSQL

In the past 5 years, I’ve used NoSQL in projects where we needed an alternative to traditional Relational Database Management Systems. This has been useful in cases where the data being stored is in a format that is not easily accessible in relational database (e.g. Blobs, images, etc.).  For example, in the digital passport project for Immigration Canada, we used NoSQL to store photographs required for training of image recognition system.

However, it’s worth noting that NoSQL is not always appropriate. In particular, when we’re accessing small blocks of data that can be stored in tables, a relational database (using SQL) is still best. For Simulation Magic, we use a combination of both, since our Big Data requires Blobs of public and private data,

This data must first be filtered and then converted into relational data that can be treated by calculation engines used for Analytics and Simulations.

Education and learning software

I’ve actually been involved with education-oriented software since the start of my work as a software engineer career, going back to the early days of my career. More recently, I’ve been designing and developing Simulation Magic, the AI-based system referred to above. This is a joint project with SOLSER Information Technology, which is based out of Mexico.

The system uses Analytics and Simulations to mitigate risk, by helping people make decisions, based on whatever information is available to them. There are many applications for this, such as managing the allocation of funds for various projects with resources competing for attention.

However, a major application is in education, where simulations can be used to create realistic scenarios that approximate real life situations. For example, this approach can be applied to any scenario where diagnostics are required.

This includes medical diagnoses, decisions by technicians, supply chain management, operations, etc.  We are presently developing various versions for the minimal viable product (MVP) that will be used by Beta users in real life environments where they need to simulate and analyze the decisions required in their everyday workplace environment (see also www.SimulationMagic.com).   

Mocking

This is an approach that has been an integral part of all of my projects for the past 5 to 10 years. Here is how defined on the Stack Overflow web site: 

"Mocking is primarily used in unit testing. An object under test may have dependencies on other (complex) objects. To isolate the behaviour of the object you want to test you replace the other objects by mocks that simulate the behaviour of the real objects. This is useful if the real objects are impractical to incorporate into the unit test. In short, mocking is creating objects that simulate the behaviour of real objects."   [1]

------------------------------------------------

References 
1. See https://stackoverflow.com/questions/2665812/what-is-mocking 
 

 

 

 

  

 

No comments:

Post a Comment