Search This Blog

May 6, 2020

6 Strategies For Migrating To AWS - A Cheatsheet

Migration to cloud is no easy task. There are a lot of planning and preparation that needs to be done before the journey even begins. But this post is not about the phases of cloud migration. 

This post is about the common strategies that are adopted by the organisations to migrate applications from on-premise to cloud. This post is not a substitute to the AWS Whitepaper on this subject, but an exam cram or cheat-sheet of sorts to aid your understanding and remember it all easily. So the cheat-sheet to 6 common strategies are:

1. Re-host

 
  • Think: Lift and Shift 
  • Times when you can automate the entire migration by way of automation with AWS Server Migration Service (SMS), without much manual intervention.


2. Re-platform

 
  • Think: Lift, Tinker and Shift 
  • Times when you take the migration as an opportunity to tinker your platform for good. Typical use case is to leverage AWS Managed Services to reduce the maintenance overheads, like using AWS Relational Database Service (RDS) in cloud. The engine is same, the platform is different. This should be analogous to situations when you use the same car for driving on icy-roads or dry-roads; just that you may tinker your car tyres with snow-chains for better friction on snow-filled roads.


3. Refactor / Re-Architect

 
  • Think: Re-modelling for better
  • Times when you refactor and/or re-architect your app in a fairly big way. Typical use case is to go cloud-native leveraging Elastic Kubernetes Service (EKS) or Elastic Container Services (ECS) by re-factoring your monolithic app as a set of microservices. Enterprises might adopt this strategy even if this is an expensive approach, should they deem the benefits out-weight the costs.


4. Re-purchase

 
  • Think: Drop and Shop
  • Times when the enterprises mimic individual shopping habits, like how we simply discard our current mobile phone for the newly launched mobile phone offering promising features. Or think of how we discard our current car for a new one. Ok that might be a stretch to think of all migrations choosing this strategy. There are umpteen occasions when this is a clear winner. Think of use-cases where:
    • Companies dropped in-house and/or disparate office tools and adopt Zoho Office Suite, because they find it fairly economical SAAS offering.
    • Companies dropped in-house code-repository service and adopt Github for good.
    • Companies dropped in-house and/or disparate Continuous-Integration/Continuous-Deployment (CI/CD) ecosystem to adopting AWS CodePipeline (which can deploy apps even on instances running on-premise!)


5. Retain

 
  • Think: Revisit later! 
  • Times when you wouldn't want to taunt the beast, like when you have mainframes systems that are managed on-premise. You know it's a beast out there that requires to be handled with great focus and deliberations. After all, you don't want to be mauled, do you?



6. Retire

 
  • Think: Decommission 
  • Times when you discover legacy apps being maintained for no apparent business value add. We all have heard of this office gossip of how some office detective in sysops-team discovered an unused or hardly used app that was silently eating the server capacity. He had the audacity to put his neck out and flag this to the management. He first got reprimanded and only later was thanked and congratulated...oh, focusing on that poor application, its now decommissioned!

May 4, 2020

Pre-Warming AWS Lambda Functions



Do you know that if your Lambda function is not invoked for a while and then invoked later, it may not be as responsive as you would wish it be?

And that is because if a Lambda function is not used for a long time (which is subjective to AWS systems as it deems right perhaps based on the demand against available capacity), AWS would re-cycle the container hosting the Lambda function. Subsequent to that for any new requests to this lambda function, AWS needs to deploy the container hosting it for the lambda function execution to happen. This overhead time of launching the container will make your new requests look a little unresponsive.

This can potentially be an issue that might surprise your team and business alike when you least expect it. To avoid such unpleasant and unwanted surprises, you can keep the container active discouraging it to be recycled by AWS infrastructure systems. AWS calls this technique as pre-warming the lambda function.

But what is the best way to put this technique in practice? In order to pre-warm the lamnda function, the best way is to call it using a schedule.

"If schedule, then AWS CloudWatch". Did your mind ring that?

AWS implements scheduling as an event source type (aka triggers) via CloudWatch Events. You can now invoke a Lambda function on a regular, scheduled basis. You can specify a fixed rate (number of minutes, hours, or days between invocations) or you can specify a Cron-like expression. In our case, we can configure a CloudWatch Event rule and select the lambda function as its target. The event is executed every minute to warm up the function so that the function stays active.

You can define this trigger:
  1. for a new lambda function at the time of defining it from Lambda Console like below:



  2. for an existing lambda function that is already deployed from Lambda Console like below:

  3. for an existing lambda function that is already deployed from CloudWatch Management Console like below:
Hope that helps!

May 1, 2020

My Experience With Pluralsight E-Learning Platform


In my earlier blog post I have shared my experience of how I could make surprisingly good use of Pluralsight's FREE April subscription, in the hope that others might draw similar mileage in times of Covid-19 pandemic uncertainty.

Now in this blog post, I'd like to continue on that and share my experience of Pluralsight platform. I had earlier used this platform sitting alongside my team members to encourage online learning in teams that I coached and consulted with. Unfortunately, I didn't explore it much back then to motivate my teams. I hope the earlier post and this one serves them well as much as I hope it serves you :)

What really clicked for me?

  • I really love the Skill IQ tests. It is not too lengthy and not too short. Most of the questions are good with custom time ticking. Check out my Pluralsight Profile for the number of tests that I took during April 2020.
  • The conferences addition is a good one. I book-marked a few but couldn't complete it all.
  • The user profile page is motivating to learn more and more. I happened to discover it mid way through the month prompting me to take more tests. It surely gamefied my experience.
  • I personally like the way learning path is crafted, although I didn't go that way during this FREE month offering.

Some of the courses I would recommend at Pluralsight


Some Authors I follow at Pluralsight


What I would wish from Pluralsight?

  • It has come a long way  from being more of a Microsoft shop. It still is in my opinion. Make it much more diverse in tech. 
  • Make it a go to place for courses related to certifications like that of AWS, Kafka, etc. This one is super competitive today, but is well worth pursuing.
  • While most questions in Skill Iq were good, there were some that lacked clarity given the dynamic time to answer that question. I tried giving my feedback on quite a few questions but got no acknowledgement or response from Pluralsight. I don't know if they have a team that is going to look into it. Wish it is a little responsive to feedback to build that affinity.
  • Okay I see Pluralsight has its own branding in the way courses are organised and structured. But I think it will be more fun to have other brands on boarded too like how O'Reilly did with Safari Online.
  • It will be super awesome to have ebooks too on this platform.
  • It will be great to have sandboxes like KataKoda for interactive learning.
  • Onboard popular authors from other platforms to have their courses in Pluralsight as well. Some of the popular authors include Stephane Maarek (for AWS), Maximilian Schwarzmuller (for ReactJS), Mumshad Mannambeth (for Kubernetes) etc.
  • Have Learning Paths tailored to Certifications and Technology. During one of my consulting stints, I was trying assemble a list of courses to help my teams go through it for Azure cloud and Kubernetes.
  • Make it more individual friendly when it comes to pricing.