Skip to main content

STACK 2020 Developers Conference

· 8 min read
Evan Tay
Evan Tay
Final year Computer Science major at NUS

STACK 2020 Developers Conference is GovTech’s flagship conference and the largest government-led developers event in Singapore that connects government, industry and the tech community.

In this post, you will find my key takeaways for some of the sessions I attended during the conference. I chose to attend these sessions based on my interests in Cloud and Microservices.

Day 1:

Day 2:

Opening note​

Speaker(s)

Key takeaways

The government believes openness is the way to building a smart nation.

On that note, they believe in:

  • Adopting the best solutions there are, including those from the industry, instead of doing everything in-house
  • Collaborating with industry developers via open-source
  • Providing transparency to citizens and industry professionals
    • TraceTogether: Transparent and open collaboration with the industry

Rethink, Reinvent, Rebuild​

Speaker(s)

  • Jeff Barr: Vice President & Chief Evangelist at Amazon Web Services

Key takeaways

  • Rethink - Take a good look at where we are
    • Everything has changed due to COVID-19, Quarantine, WFH
    • No firm ground and constants are now variables
    • People are more receptive to change and invention right now
    • Good time for innovation and progress
  • Reinvent - Solve challenges in a new way
    • Dream big dreams, address these challenges, change the world
    • Share what you learn to reinforce what you learned
      • Content creation / video streaming possibilities
  • Rebuild - Put what you have learned to work
    • Take what you learn, do something awesome, and remember to share it!

Seeding the Cloud: Engineering Solutions for Cloud Adoption​

Speaker(s)

Key takeaways

Hunter shared about how GovTech uses Infrastructure-as-Code (IaC) and Policy-as-Code (PaC) to accelerate cloud operations. Read #devops-cloud-and-back-again by Hashicorp CTO Mitchell for more information.

  • Establishing a Landing Zone
    • A repeatable configuration across multiple Cloud Service Providers (CSP)
    • The foundation of any cloud environment at scale
    • Serves as a consistent platform for governance, onboarding, networking and security
  • Accelerating deployment with Infrastructure-as-Code (IaC)
    • Code and configuration to provision cloud resources and Landing Zones
    • Develop common templates for consistency and familiarity
    • Get feedback on pain points faced by "customers" while using said templates
  • Consistent audit and reporting with Policy-as-Code (PaC)
    • Code and configuration to test and validate cloud infrastructure deployed by IaC
    • Reduce need for manual audits and speed up auditing process

Six Principles for Refactoring a Monolith to Microservices​

Speaker(s)

Key takeaways

Quote

"A Microservice application is structured as a set of loosely coupled services that can be independently deployed." - Chris Richardson

Chris shared 6 principles to follow when moving from a Monolith to a Microservice architecture.

Here are 5 of them 😉 :

  • Adopt Microservice architecture for the right reasons
    • Monolith architecture is not necessary bad (an anti-pattern), it has its valid use-cases
    • Adopt Microservice architecture because it allows you to deliver software rapidly, frequently and sustainability, with small, autonomous teams working on the different microservices
  • Migrate to Microservice architecture incrementally rather than via Big Bang rewrite
    • Strangler Application: Incrementally migrate functionality from existing Monolith application to new Strangler Microservice application
      • Extract existing code modules and database tables out into microservices
      • Implement new features as microservices
  • Consider Return-on-Investment when deciding which modules to convert into microservices
    • Consider benefit of decoupling said module
    • Consider cost of decoupling
      • How difficult it is to do so
      • How many inbound dependencies it has
        • If module A is depended upon by module B, consider extracting module B first
  • Define the service boundaries correctly
    • Avoid Runtime Coupling
      • Reduced availability due to reliance of a given microservice on another for serving a given request
        • For example, microservice A receives an API request which it can only respond to when its own API request to microservice B is answered first
      • Make microservices as self-contained as possible
        • Able to respond to a request without making follow-up requests to other microservices
    • Avoid Design-Time Coupling
      • Similar to Open-Closed Principle
      • Avoid having to modify other microservices when modifying a given microservice
      • Must be able to modify or exend a given microservice independently as much as possible
        • Have small and stable API which hides as much implementation complexity as possible
        • Hide what you can, not only code but also database schemas, so you can change them without affecting other microservices
  • Measuring success
    • Improved metrics: Reduced lead time, deployment frequency, failure rate, etc.
    • Improvements in other '-ilities': Availability, Reliability and Scalability

You Won’t BELIEVE This HACK to Improve Your Technical Communication!​

Speaker(s)

Key takeaways

When introducing non-technical folks to coding, keep in mind that the most important objective is to convey understanding of core programming concepts.

On that note, here are some tips Nikhil shared:

  • Forgo coding best practices if doing so make it easier for the audience to understand
    • Reduce surface area to increase accessibility, even if it is not good coding practice
      • Collapse all HTML, JS and CSS into a single file so students can view everything in one place
      • Collapse all functions into one for the same reason as the previous line
      • Combine program lines if it makes things clearer
  • Use real-world examples to explain technical concepts
    • For example, use a restaurant scenario to explain async
  • Enable students in sharing their joy/achievement
    • Make deploying their application easy
      • Can use Netlify Drop: Simply drag and drop your HTML, JS, CSS files and Netlify Drop will do the rest for deployments
  • Practise empathy consciously throughout teaching process to identify ways you can make learning easier for your students

DevOps: Cloud and Back Again​

Speaker(s)

Key takeaways

Mitchell shared more about the Cloud Operating Model during this session.

Cite

"The Cloud Operating Model is a new approach for IT operations that organizations need to use to be successful with cloud adoption and thrive in an era of multi-cloud architecture." - Hashicorp

StaticDynamic
RunDedicated infrastructure to run app onScheduled automatically across a fleet (e.g. AWS Auto-Scaling Group, Hashicorp Nomad)
ConnectHost-based, static IP-addressingService-based, dynamic IP addresses due to dynamic provisioning
SecureHigh-trust environment which is IP-address-based, with clear network perimeterLow-trust environment with no clear perimeter given multi-tenancy and nature of the Cloud
ProvisionDedicated resources - Physical servers, routers and switchesCapacity on-demand, provision VMs, Containers and other managed services, or simply use Serverless services
  • Infrastructure operations on the Cloud must follow the Dynamic Cloud Operating Model fully
    • Pointless if you provision infrastructure in minutes using Infrastructure-as-Code (IaC), but still manually handle connectivity and security review using tickets
    • Have to adopt dynamic cloud operating tools for all 4 layers
  • Why use IaC for provisioning
    • Split Execution from Definition
    • Execution can be automated and carried out via API, UI or automatically through Continuous-Integration (CI) tools
  • How can teams use IaC
    • Operations team still necessary, focus on creating and improving blueprints and handling edge-cases when doing so
    • Development team creates infrastructure in a self-service manner, using the blueprints created by the Operations team separating buzz words from crucial tech

Read up on Hashicorp's white paper on Cloud Operating Model for more information.