What if the testing scope changed from usual UI or API testing? Instead, the testing scope gets diverted to the testing of docker artifacts like base images (let's say python, node) used in the Dev or QA community. What can be the overall possible quality gates for this ecosystem?

And the most important question is, why the testing scope needs to be changed? Isn't it testing UI or API alone sufficient? 'Not Always'. The exact answer lies in the kind of architecture/ecosystem projects have. But certainly, there are threats that can be avoided at the earlier stage by asserting quality gates, examples:

1. Vulnerability Issues
2. Performance Issues 
3. Infrastructure Configuration Related Issues and many more.

The world is shifting from waterfall to Agile ways of development and technology is changing fast.  Amidst all this, security teams are not able to keep up with this pace. This has led to increase in the number, size and frequency of breaches &  supply chain attacks.

In this talk, we discuss how to hack the developer mindset to Build Security into the product/application; also, the methods and means to make it effective at scale.

Here, I discuss the actual outcomes of this approach and share learnings from successful execution of the ‘Security Champion Program’ that I designed & drove at scale. This program proved to be effective and was run for ~ 200 teams comprising of ~3000 developers and continues to grow.

During this process, we captured hundreds of threats, taking them through a structured approach to track, manage and mitigate these issues on their project/devOps dashboard. In this talk, we also share what good looks like when Security is everyone's responsibility.

As per IDC, 81% of enterprises are using multiple public clouds along with one or more private cloud deployments. Opting for a multi cloud strategy is becoming a necessary requirement for most organization driven by many business imperatives such as: leverage best-of-breed services, address business continuity, avoid vendor lock-in etc. 

Most enterprises struggle with the complexity of multi cloud strategy when they approach it as a reactive response rather than a strategic initiative. We propose a structured framework for building a successful and long term multi cloud strategy which consists of 3 critical lenses: 1) assess the workload  2) select technology and topology and 3) establish cloud operating model. In this session, we cover this multi cloud strategy framework along with pragmatic tips on working with multi cloud. 

Every organisation is moving to cloud today and yet security still remains an afterthought. This is one challenge holds them back and prevents the team from leveraging the benefits of the cloud fully.There generally is confusion around shared responsibility on cloud but primarily often times teams lack of structured approach to deal with cloud security issues. Additionally too many security products/tools confuses the development/infra teams further.

With our experience at Thoughtworks we have come with a framework that helps to deal with this very ambiguity and complexity. In this talk, we discuss the five pillars of cloud security to be able to steer through the complexity and discuss practical challenges and starting points for teams. Here we will also discuss, how to define your cloud security strategy, what to prioritise and account for in the various cloud contexts depending on where you are in your cloud journey.

A predictable system is a myth. System failures are inevitable. The only way out is to be prepared for failures by building resilient systems and we explore chaos engineering as a way to do exactly that. Chaos testing, a part of Site Reliability Engineering (SRE), is the art of simulating unexpected system failures to test system response and recovery plan.

Session covers the "How" by showcasing live demo of chaos testing as network disruption and out of storage on workloads deployed on a Kubernetes cluster using Litmus chaos toolkit. Also talk about practical tips on approaching how to get chaos testing as part of your path to production and delivery with confidence. Going to share tips, tricks and gotchas while getting chaos engineering practice in your organisation. 

Any transformation journey usually has a roadmap that focuses on process, tools, technology and people. Studies have shown that some key reasons why transformations fail are due to cultural aspects. However, culture is often ignored and we expect magic to happen quickly. Hence, a transformation needs to weave in culture shift as a critical part of the roadmap.

We delve into…

• What constitutes culture?
• Why should a transformation look into culture shift?
• A ‘culture gauge’ as a tool to calibrate the cultural aspects
• The E3R model as a recipe to plan the culture shift journey
• The elements of ‘thin slice’ and ‘1% improvement’ as key ingredients

… we weave in our stories of failure, some good practices and envision how we would use the culture gauge and E3R model.

In today’s era of technology led businesses, developer effectiveness and experience is key to business agility and building new age engineering solutions.Some key challenges and frictions observed when building a  large-scale enterprise system involving multiple teams and/or vendors are - slow speed of delivery, low business agility, hard to do innovation at scale and low cross team collaboration leading to siloed teams and duplication of effort. And due to these challenges, significant time of engineering teams go in mundane, non-value added activities thus reducing overall effectiveness and joy at work!

Our proposal to solve the above common organizational challenges is an Engineering platform which can comprise of various building blocks ranging from but not limited to self-service delivery infrastructure, developer experience portal for knowledge sharing and collaboration across teams and dashboards for delivery and business metrics to track progress. Building such platforms is a long term program and not a point solution, as this needs proper change management and adoption at organization level. 

We at Thoughtworks have already done it by building “NEO” - our internal engineering platform!

In this talk we are going to talk about all of the above and also provide guidelines, share tips & tools regarding recommended approach towards building an engineering platform that helps to maximize developer effectiveness leading to better organizational experience and achievement of business goals. We will use NEO as a case study to contextualize why, what and how of engineering platforms.

In todays technology lead business paradigm, business agility and speed of delivery is key challenges that every organisation is struggling with. And one of key enablers for it is to enable development teams with better infrastructure, ease in sharing information and space for collaboration. Which eventually leads to developer ecosystem. Developer ecosystem is fragmented and needs lot of effort for onboarding and collaboration. Backstage.IO is an open source platform that helps bring all these fragmented system under one single pane of glass and build cohesive view for developers, engineering teams and product teams. Such Internal developer portal helps product teams to share knowledge, collaborate and track progress together. 

In this demo session, we will walk you through features of Backstage.IO platform, showcase some of interesting features that can help teams as low hanging fruits quickly, how to extend platform by writing your own plugins and specially antipatterns and quirks of the platform and how to overcome it.

Serverless architectures offer elasticity, low entry cost and faster time to market without the operational overhead of managing servers. They are proven to be effective in many use cases such as Event Streaming, IoT data processing, Chatbots, Cron jobs, Microservices, etc. Serverless first mindset for building end to end solutions using serverless stack. 

The session will demonstrate the IoT reference architecture build using serverless stack end to end. When building cloud native applications you can leverage the entire serverless stack starting from compute, object store, database, messaging, etc. During the talk we will demonstrate the building of an entire IoT Reference Architecture using serverless components leveraging Azure serverless services. We will demo on how IoT devices (Raspberry Pi with few sensors) will securely connect and transmit data to Cloud gateway. We will see in action how the IoT data streaming using serverless data ingestion and further storing time-series telemetry data efficiently with serverless databases.

The session will also touch base on Serverless design patterns about how to leverage Hexagonal architecture as a serverless design pattern which enables easy migration to any cloud vendor (Avoid vendor lock-in) with least impact to the application if the need arises.

Serverless is definitely a step closer towards NoOps and becoming the de facto standard for building greenfield Cloud native applications.