Siamak Sadeghianfar

Principal Technical Marketing Manager, OpenShift, Red Hat

Siamak Sadeghianfar

Siamak Sadeghianfar is a Principal Technical Product Marketing Manager for OpenShift at Red Hat and strives to educate IT professionals, customers and partners on all aspects of application development with containers and how new technologies can be used to solve business problems quicker and with less friction. A developer at heart, he is passionate about application development lifecycle, processes, and architecture and has 15+ years of experience in the IT industry.

Areas of Expertise

Java, Application Architecture, Containers, OpenShift

Recent Posts

Using Ansible Galaxy Roles in Ansible Playbook Bundles

ssadeghi
By Siamak Sadeghianfar

[In case you aren’t following the OpenShift blog, I’m cross posting my article here because I think it will be of interest to the Red Hat Developer commnity.]

The Open Service Broker API standard aims to standardize how services (cloud, third-party, on-premise, legacy, etc) are delivered to applications running on cloud platforms like OpenShift. This allows applications to consume services the exact same way no matter on which cloud platform they are deployed. The service broker pluggable architecture enables admins to add third-party brokers to the platform in order to make third-party and cloud services available to the application developers directly from the OpenShift service catalog. As an example AWS Service Broker created jointly by Amazon and Red Hat, Azure Service Broker created by Microsoft and Helm Service Broker created by Google to allow consumption of AWS services, Azure services and Helm charts on Kubernetes and OpenShift. Furthermore, admins can create their own brokers in order to make custom services like provisioning an Oracle database on their internal Oracle RAC available to the developers through the service catalog.

Continue reading “Using Ansible Galaxy Roles in Ansible Playbook Bundles”

Share

Getting Started with Istio and Jaeger on Your Laptop

ssadeghi
By Siamak Sadeghianfar

[Cross posted from the OpenShift blog]

About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating, and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.

As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content:

  • learn.openshift.com: A web-based OpenShift and Kubernetes learning environment where users get to interact through the web browser with a real running instance of OpenShift and Istio service mesh with zero install time and no sign-up required.
  • Istio tutorial: Want to try the web-based scenario yourself from scratch? This Git repo contains instructions on how to set up an environment for yourself.
  • Introducing Istio Service Mesh for Microservices book by Christian Posta and Burr Sutter
  • Blog posts on the OpenShift and Red Hat Developer blogs

Continue reading “Getting Started with Istio and Jaeger on Your Laptop”

Share

Red Hat Summit Spotlight: Getting Started with Cloud-Native Apps Lab

ssadeghi
By Siamak Sadeghianfar

Cloud-native application development is the new paradigm for building applications and although is it often mistaken for microservices, it is much more than that and encompasses not only the application architecture but also the process through which applications are built, deployed, and managed.

New apps are often seen as the focus of cloud-native applications; however, we believe existing and new applications are alike and can incorporate cloud-native practices if they have the four defining characteristics of cloud-native applications:

  • Service-based: Build modular loosely coupled services (for example, microservices).
  • API-driven: Expose services via lightweight technology-agnostic APIs.
  • Containers: Package and deploy in containers as a portable unit of compute.
  • DevOps: Adopt agile and DevOps principles.

The Getting Started with Cloud-Native Apps lab at Red Hat Summit 2018, which takes place in San Francisco on May 8–10, has a packed agenda that focuses on walking participants through the principles of building and operating cloud-native applications.

Continue reading “Red Hat Summit Spotlight: Getting Started with Cloud-Native Apps Lab”

Share
Red Hat Logo

Building Declarative Pipelines with OpenShift DSL Plugin

ssadeghi
By Siamak Sadeghianfar

Jenkinsfiles have only become a part of Jenkins since version 2 but they have quickly become the de-facto standard for building continuous delivery pipelines with Jenkins. Jenkinsfile allows defining pipelines as code using a groovy DSL syntax and checking it into source version control which allows you to track, review, audit and manage the lifecycle of changes to the continuous delivery pipelines the same way that you manage the source code of your application.

Although the groovy DSL syntax which is called the “scripted syntax” is the more well-known and established syntax for building Jenkins pipelines and was the default when Jenkins 2 was released. Support for a newer declarative syntax is also added since Jenkins 2.5 in order to offer a simplified way for controlling all aspects of the pipeline. Although the scripted and declarative syntax provides two ways to define your pipeline, they both translate to the same execution blocks in Jenkins and achieve the same result.

Continue reading “Building Declarative Pipelines with OpenShift DSL Plugin”

Share
Kubernetes logo

How Kubernetes Helps to Enable DevOps

ssadeghi
By Siamak Sadeghianfar

A recent Gartner survey suggests that roughly 50% of the respondents planned to implement continuous delivery and DevOps by year-end 2017 in order to deliver services faster, more often and more reliably. State of DevOps Report by Puppet Labs suggests that high-performing organizations that focus on automation and DevOps are able to reduce their lead-time for delivering a change by a factor of 440 and deliver services 46 times more often. These results have helped to make DevOps adoption a mainstream enterprise IT phenomena. As a result, today we see DevOps adoption in virtually all industries and company sizes, and the perception of DevOps as a unicorn capability has long vanished.

Continue reading “How Kubernetes Helps to Enable DevOps”

Share