GCP
Challenge number #1 - in a foreign land - GCP to the rescue.
Being brought into a new technical situation is always challenging—the challenges compound when the timeline and budget are tight. When faced with these constraints, the seasons of consulting with different companies and different situations are beneficial.
When contemplating the architecture of Notch and also considering the design and technical constraints - which are many - experience and creativity are welcome allies.
My background is in AWS and Azure, but only in architecture - no real hands-on experience. Leaning on the familiar is only natural. So now's the time to roll up the sleeves and dive-in.
Listening to the desired outcome (the Notch website) and understanding the companies current technical composition, I created the preferred architecture for Notch—Hybrid, with full intention to migrate to the cloud.
With little time to learn, my experience with Azure and AWS's interface was not a pleasant one. Again, I know how to architect cloud solutions; I don't usually implement them. And guess what, when you have resource constraints, you get no help from these cloud providers. So I decided to peek over the wall at Google's playground. The more I read, the more I found Google to be a viable alternative for Notch's foundation. The architecture is in mind; I need fast execution. During my experience, I found the Google tools easier to use (and I use the word easy relative to the other cloud platforms); I also like the fact that there is no vendor lock-in.
One of the things I learned relatively quickly is that deployment can occur in many flavors, and the choice in deployment can also dictate how you are charge by Google.
The initial direction was to use Google's App Engine to host a REST API. Now when I say REST, I mean REST (another article for another day). However, more reading and understanding of the technology available in Google's Cloud Platform (GCP) lead to Cloud Run's discovery.
Cloud Run allows for the deployment of containers and scales dynamically. The fact that I could deploy a self-contained application with all dependencies appealed to me a lot. And one of the things I will generously kick myself for is not understanding and embracing the benefit of containers. However, I am finding a container running on my local machine vs. GCP does generate a different result.
The technical need is to isolate the data through a brokering mechanism so that when data is needed it must be requested and only returned to known requestors. Running in a container on Google's Cloud Run and acting as a broker for data does this very nicely for Notch. The additional luxury of only having to secure one endpoint is also lovely.
The current Notch implementation is the beginning of the Server-less journey.
When contemplating the architecture of Notch and also considering the design and technical constraints - which are many - experience and creativity are welcome allies.
My background is in AWS and Azure, but only in architecture - no real hands-on experience. Leaning on the familiar is only natural. So now's the time to roll up the sleeves and dive-in.
Listening to the desired outcome (the Notch website) and understanding the companies current technical composition, I created the preferred architecture for Notch—Hybrid, with full intention to migrate to the cloud.
With little time to learn, my experience with Azure and AWS's interface was not a pleasant one. Again, I know how to architect cloud solutions; I don't usually implement them. And guess what, when you have resource constraints, you get no help from these cloud providers. So I decided to peek over the wall at Google's playground. The more I read, the more I found Google to be a viable alternative for Notch's foundation. The architecture is in mind; I need fast execution. During my experience, I found the Google tools easier to use (and I use the word easy relative to the other cloud platforms); I also like the fact that there is no vendor lock-in.
One of the things I learned relatively quickly is that deployment can occur in many flavors, and the choice in deployment can also dictate how you are charge by Google.
The initial direction was to use Google's App Engine to host a REST API. Now when I say REST, I mean REST (another article for another day). However, more reading and understanding of the technology available in Google's Cloud Platform (GCP) lead to Cloud Run's discovery.
Cloud Run allows for the deployment of containers and scales dynamically. The fact that I could deploy a self-contained application with all dependencies appealed to me a lot. And one of the things I will generously kick myself for is not understanding and embracing the benefit of containers. However, I am finding a container running on my local machine vs. GCP does generate a different result.
The technical need is to isolate the data through a brokering mechanism so that when data is needed it must be requested and only returned to known requestors. Running in a container on Google's Cloud Run and acting as a broker for data does this very nicely for Notch. The additional luxury of only having to secure one endpoint is also lovely.
The current Notch implementation is the beginning of the Server-less journey.