0 comments on “Podcast –Nick Alesandro on Blockchain, Edge, and Cloud Oh My!”

Podcast –Nick Alesandro on Blockchain, Edge, and Cloud Oh My!

Joining us this week is Nick Alesandro, VP of Product at Overclock Labs; creators of The Akash Network.

About Overclock Labs

  • We believe the Cloud should be distributed and decentralized so that no one provider can control the internet.
  • We believe the cloud should be globally fault-tolerant to avoid any single points of failure.
  • We believe the Cloud should be simple, automated, and accessible for all.

About Akash Network

Decentralized protocol for provisioning, scaling and securing cloud workloads: The world’s only on-chain auction marketplace for off-chain container deployments

Highlights

  • 0 min 37 sec: Introduction of Guest
  • 2 min 28 sec: High level description of the technology
    • Cloud centralization is a problem; it needs to be decentralized
    • Take over 100% or a partial amount of a machine added to the cloud network with special CoreOS based system
  • 5 min 13 sec: Akash Network
    • Donate your idle servers into an available system for usage in a cloud managed by Overclock Labs
    • 2 Components – Blockchain for marketplace / Deployment platform
  • 6 min 52 sec: How does marketplace work; who wants to use this network?
    • Focus is on developers who want to use these systems
    • #1 Reason – Cheaper than standard public clouds ; #2 Reason – Its distributed globally not at fixed known sites
  • 10 min 26sec: Blockchain as decentralized ledger to avoid central store
    • Join the infrastructure without a formal registration on a single database; only listening for bids not publishing what they offer
    • History of the infrastructure is public for customers to evaluate
  • 12 min 31 sec: How do I know where I am pushing my workloads? Can I trust the infrastructure provider?
    • Issues arise with receiving workloads that are unknown to you
  • 16 min 38 sec: What do I do to add a rack of servers into Akash network?
    • What you need to do vs what you should do
    • Management Server, Network Isolation, Monitoring
    • Seasonal Load Model ~ Electric Grid Analogy
  • 20 min 23 sec: Identify Geography and Latency to Customers?
  • 21 min 23sec: What do I ensure I am not getting dropped or pulled into a bidding trap?
    • Workload goes down it automates a bid elsewhere in the network
    • Conditions can be set should you need a long running workload and it is terminated by the host
    • Do you expect providers to monitor machines or do you as a service?
  • 27 min 45 sec: Kubernetes Cluster across providers?
    • Kubernetes Federation
    • Why Kubernetes? Writing our own Kubernetes using Kubernetes
  • 31 min 55 sec: Why not do this with Virtual Machines?
    • Containers makes sense
  • 32 min 40 sec: How long have you been working on this project?
    • Why of the project? DISCO → Scheduler
    • Decentralization is the key
    • Can build a private infrastructure using their system
  • 37 min 01 sec: Wrap-Up
0 comments on “Podcast – Jordan Rinke on Open Source, Kubernetes, and Edge Computing”

Podcast – Jordan Rinke on Open Source, Kubernetes, and Edge Computing

Joining us this week is Jordan Rinke, Principal Software Engineer, Walmart Labs. Jordan offers his views on various technologies and open source projects as it relates to the scale and connectivity issues faced by Walmart.

Highlights

  • Technical Gaps in Kubernetes Technologies and Installer Issues
  • Tooling and Orchestration Focus for Kubernetes and Other Tools
  • Core OS Model for Bootstrapping Kubernetes
  • Discussion on Immutability: Middle Ground for Jordan
  • Edge Computing – Emerging markets lead to disconnected edge sites
  • Data location challenges in edge and cloud services
  • Skills issues for medium sized clusters

Topic                                                                                    Time (Minutes.Seconds)

Introduction                                                                            0.0 – 1.08
Jet and Walmart Integration                                                1.08 – 1.57
Open Source & Walmart                                                      1.57 – 3.18
Kubernetes Challenge & Opportunities                             3.18 – 6.25
Open Source Installation Tool Sprawl                                6.25 – 9.53
Kubernetes to Bootstrap Kubernetes (CoreOS Model)   9.53 – 12.28
Ephemeral Hardware and Immutability                            12.28 – 15.30
Edge Computing                                                                   15.30 – 20.18
Dynamic Data Locations                                                      20.18 – 22.44
Medium Scale Clusters                                                        22.44 – 26.39 (On-Prem Kubernetes)
Wrap Up (OpenStack Bus Tour)                                          26.39 – END

Podcast Guest: Jordan Rinke

Technically inclined executive with 7 years of team leadership and startup growth experience:
Leading teams from 4 to 20 people in size on highly technical tactical and responsive issues. Managing the teams that have helped a number of startups secure funding from $50k to $1.5MM+ and effectively utilizing that investment to grow a sustainable energetic culture and product portfolio.

Before that I accrued 10 years of dev/eng experience (6 years of fortune 50 company experience, 4 years at one of the world’s largest cloud providers) doing OS deployment (DevOps before it was a buzz word) and driver integration for environments with over 150,000 devices giving me a unique perspective on large scale deployment scenarios.

1 comment on “LinuxKit and Three Concerns with Physical Provisioning of Immutable Images”

LinuxKit and Three Concerns with Physical Provisioning of Immutable Images

DR ProvisionAt Dockercon this week, Docker announced an immutable operating system called LinuxKit which is powered by a Packer-like utility called Moby that RackN CTO, Greg Althaus, explains in the video below.

For additional conference notes, check out Rob Hirschfeld’s Dockercon retro blog post.

Three Concerns with Immutable O/S on Physical

With a mix of excitement and apprehension, the RackN team has been watching physical deployment of immutable operating systems like CoreOS Container Linux and RancherOS.  Overall, we like the idea of a small locked (aka immutable) in-memory image for servers; however, the concept does not map perfectly to hardware.

Note: if you want to provision these operating systems in a production way, we can help you!

These operating systems work on a “less is more” approach that strips everything out of the images to make them small and secure.  

This is great for cloud-first approaches where VM size has a material impact in cost.  It’s particularly matched for container platforms where VMs are constantly being created and destroyed.  In these cases, the immutable image is easy to update and saves money.

So, why does that not work as well on physical?

First:  HA DHCP?!  It’s not as great a map for physical systems where operating system overhead is pretty minimal.  The model requires orchestrated rebooting of your hardware.  It also means that you need a highly available (HA) PXE Provisioning infrastructure (like we’re building with Digital Rebar).

Second: Configuration. That means that they must rely on having cloud-init injected configuration.  In a physical environment, there is no way to create cloud-init like injections without integrating with the kickstart systems (a feature of Digital Rebar Provision).  Further, hardware has a lot more configuration options (like hard drives and network interfaces) than VMs.  That means that we need a robust and system-by-system way to manage these configurations.

Third:  No SSH.  Yes another problem with these minimal images is that they are supposed to eliminate SSH.   Ideally, their image and configuration provides everything required to run the image without additional administration.  Unfortunately, many applications assume post-boot configuration.  That means that people often re-enable SSH to use tools like Ansible.  If it did not conflict with the very nature of the “do-not configure-the-server” immutable model, I would suggest that SSH is a perfectly reasonable requirement for operators running physical infrastructure.

In Summary, even with those issues, we are excited about the positive impact this immutable approach can have on data center operations.

With tooling like Digital Rebar, it’s possible to manage the issues above.  If this appeals to you, let us know!